Re: WSL-4.0 release candidate

On Tue, Mar 5, 2013 at 10:07 AM, Earnie Boyd wrote:
> On Mon, Mar 4, 2013 at 12:13 PM, Keith Marshall wrote:
>> What about the following (untested) alternative?
>>
>> * In its own XML catalogue, create a definition for a wsl-candidate
>> package; this will be a dummy package, delivering only a replacement for
>> var/lib/mingw-get/data/mingw32-runtime.xml itself, (as payload of
>> wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz, say).
>>
>> * Add a reference for this new catalogue to mingw32-package-list.xml
>>
>> * Publish the new catalogue, and the updated package list.
>>
>> * Make a private local copy of mingw32-runtime.xml, (perhaps within a
>> private local git branch of mingw-dist).
>>
>> * Add your "release" specs for mingwrt-4.0 and w32api-4.0, as if you
>> were making a formal release; DO NOT PUBLISH THIS!
>>
>> * In your working directory, (taking care not to destroy anything you
>> really want to keep):
>>
>>     rm -rf var
>>     mkdir -p var/lib/mingw-get/data
>>     sed s/@YYYYMMDDNN@/ZZZZZZZZZZ/ mingw32-runtime.xml \
>>       > var/lib/mingw-get/data/mingw32-runtime.xml
>>     tar cf - var | xz -c > wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz
>>
>> * Publish the resultant tarball.
>>
>> Now, users may opt in to testing your candidate, by running:
>>
>>     mingw-get update
>>     mingw-get install mingw32-wsl-candidate
>>     mingw-get upgrade mingw32-mingwrt mingw32-w32api
>>
>> and may opt out again, by:
>>
>>     mingw-get remove mingw32-wsl-candidate
>>     mingw-get upgrade --reinstall mingw32-mingwrt mingw32-w32api
>
> I'm not seeing how this scenario is going to work correctly.  The
> modified mingw32-runtime.xml will still be existent and the upgrade
> --reinstall will install the RC.
>
>
> On Mon, Mar 4, 2013 at 3:25 PM, Keith Marshall wrote:
>> On 04/03/13 19:44, Earnie Boyd wrote:
>>> On Mon, Mar 4, 2013 at 12:13 PM, Keith Marshall wrote:
>>>> On 02/03/13 16:41, Earnie Boyd wrote:
>>>>> How about:
>>>>>
>>>>> rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma
>>>>>
>>>>> or
>>>>>
>>>>> mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma
>>>>>
>>>>> Would either of these produce the result I'm looking for?
>>>>
>>>> Either may, but the former is unacceptable.
>>>
>>> Why is it unacceptable.  I tested it and it actually works well.
>>
>> It may *appear* to work, but you now have two disparate and conflicting
>> packages, each claiming to own (at least a subset of) the same payload
>> of installed files.  Install one, or the other, and things will surely
>> appear to work out okay.  Even install both together, and it may still
>> seem to work.  Now, with both installed, remove just one, and you'll
>> break the other.
>>
>> You are creating a scenario in which mingw-get must lose track of what
>> files have been installed by which package; IOW, a recipe for confusion
>> and potential problems down the line.
>>
>
> I don't see mingw-get losing track and I don't see how the alternate
> scenario you've given is that much different.  There are two separate
> packages (mingwrt and rc_mingwrt), that have similar file sets.  Yes,
> if you remove one of those packages then you must reinstall one or the
> other and that is a caveat for the user using the release and is
> easily corrected by the user; but this is the case with your alternate
> scenario as well.
>
> With my design the user would
>
> mingw-get update
> mingw-get install mingw32-rc_mingwrt mingw32-rc_w32api
>
> to use the RC and then to fall back to the previous version would simply do
>
> mingw-get remove mingw32-rc_mingwrt mingw32-rc_w32api
> mingw-get install --reinstall mingwrt w32api
>
> I think the msys-core and msys-coreutils scenario is even more
> confusing than what I'm proposing.

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.

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