Re: WSL-4.0 release candidate

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.  That's going to break the dependency chain 
for GCC, behind mingw-get's back.  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?

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).  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 [*].

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.

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.

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

[*] 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.

-- 
Regards,
Keith.

------------------------------------------------------------------------------
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