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@.../ 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:
>>>>> 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.