Re: WSL-4.0 release candidate

Keith does my retort satisfy your concerns?

On Tue, Mar 12, 2013 at 11:07 AM, Earnie Boyd wrote:
> 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

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar