Re: WSL-4.0 release candidate

On Mon, Mar 11, 2013 at 7:15 PM, Keith Marshall wrote:
> On 11/03/13 18:49, Earnie Boyd wrote:
>>> However, I understand that I should put the package meta data in its
>>> >own file.  Otherwise, it would have to remain in mingw32-runtime.xml.
>>> >I could name that mingw32-wsl-candidate.xml.
>> Ping.
>
> Separation of the package meta-data isn't the issue; the overlap in
> package content is.
>
> You are advocating that users who would like to test your release
> candidate should mingw-get remove the original package, then install a
> *different* package instead.

Uh, no I'm not.
mingw-get install mingw32-rc_mingwrt mingw32-rc_w32api
This doesn't remove the existing package from mingw-get.  It installs
an alternate set of the same files.

> That's going to break the dependency chain
> for GCC, behind mingw-get's back.

No, it doesn't, the dependency is still intact.

> If a user, having followed your bogus
> installation path, subsequently touches GCC again, with mingw-get, who
> can tell what sort of mess is likely to ensue?
>

Touches how?
mingw-get install --reinstall gcc
will only reinstall
~~~~~~
reinstall: gcc-4.7.2-1-mingw32-lic.tar.lzma
 installing gcc-4.7.2-1-mingw32-lic.tar.lzma
reinstall: gcc-core-4.7.2-1-mingw32-bin.tar.lzma
 installing gcc-core-4.7.2-1-mingw32-bin.tar.lzma
reinstall: gcc-4.7.2-1-mingw32-doc.tar.lzma
 installing gcc-4.7.2-1-mingw32-doc.tar.lzma
reinstall: gcc-4.7.2-1-mingw32-lang.tar.lzma
 removing release gcc-4.7.2-1-mingw32-lang.tar.lzma
 installing gcc-4.7.2-1-mingw32-lang.tar.lzma
~~~~~~
The only possible collision is that the files from mingw32-mingwrt and
mingw32-w32api are installed again over top of the mingw32-rc_mingwrt
and mingw32-rc_w32api packages.  That isn't a hell raising issue.

> You are proposing to violate the packaging rules we agreed, in the early
> days of mingw-get's development; (stated mathematically, in terms of set
> theory, that policy was that the intersection of the sets of files to be
> installed by any two distinct packages shall be the empty set).

The package names are different.  The files are named for the package
they represent.  The contents of the files happen to be similar.
There is no violation of rules.

>  I
> consider such policy violation to be unacceptable, and have stated this
> previously.  You may disagree, to the extent that the declaration of
> unacceptability is too strong, but the course you propose is definitely
> unsafe [*].
>

I don't see this as unsafe, I've tested the methods.  The potential
hazard is the end user removes one or the other package and thus
leaves the files associated with that package removed.  Easily
correctable by a --reinstall of the package he wants to keep.  There
is no harm to the mingw-get data regardless of the end user action.

> The better way to handle this is to publish the package upgrades, as if
> they were formal releases of the existing mingwrt and w32api packages,
> but to hold back the catalogue updates, while making previews of those
> catalogue updates available to users who wish to test the candidate
> releases.  The alternative technique which I suggested does just that,
> by installing a preview catalogue in place of the formally published
> version, while setting its issue serialisation attribute to lock it
> against "mingw-get update", without interfering in any way with
> mingw-get's package dependency chains.
>

And I stated that I didn't see how your alternate method can work as you stated.

> If, having installed that preview catalogue, a user wishes to revert to
> the official release state, they simply mingw-get remove the preview
> catalogue, and mingw-get will automatically replace it with the formally
> published version, the next time it is invoked.
>

And so it is with my method as well.
~~~~~~
mingw-get remove mingw32-rc_mingwrt mingw32-rc_w32api
mingw-get install --reinstall mingw-32-mingwrt mingw32-w32api
~~~~~~
How does this cause any headache with your [*] bullet?

> IMO, that is a much safer way to achieve your desired effect.
>

I still do not see the benefit in safety or workability in your procedure.

> [*] Furthermore, when I eventually get reverse dependency look-up
> working for mingw-get remove, your proposed technique will cease to be
> an option; the removal of the pre-requisite package will be prohibited.
>

As stated already, the removal of mingw32-mingwrt and mingw32-w32api
is not a requirement nor published method.
Those prerequisite packages still exist as far as mingw-get is
concerned; I've published different packages.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev