Re: WSL-4.0 release candidate

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.

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