Re: Bug in upset? [Was: Re: R: Problem [1.7]: link /bin/lzma -> xz]

["Charles Wilson" <cygwin at cwilson dot fastmail dot fm>]

Christopher Faylor wrote:
> I don't understand how you'd posit this as an upset bug if upset is
> working correctly for the release directory.  That implies a difference
> between the two directories, not an upset bug.

I didn't notice the missing -3 version, because I didn't expect it to be
there. The "correct" obsolete version number for lzma in release-2 is
-10 -- and it was there.  I also wasn't sure if upset runs in a
different "mode" for release-2, other than "look in this directory
instead of that one, and put the output in this file instead of that". 
(I wouldn't expect that it does, but...)
 
> And, in fact, there was no lzma-4.32.7-3*tar.bz2 files in the lzma
> directory.  Apparently they were deleted on March 16.  I ressurrected
> them.

Urk. Now I remember. Normally, when I'm forking a package for 1.7, I do
the following:
1) install "lower number" in release/
2) delete the copies in release/
3) install "higher number" in release-2/
(it's a little odd when the "forked" package is ALSO simultaneously
being made obsolete...why "fork" it at all? Eh...)

That's ok. However...THIS was the problem:

"And the two lzma/setup.hints are identical."

That's usually correct -- unless you're trying to explicitly specify
prev: and curr: versions. When installed like I have been, the numbers
are different, and the setup.hints *ought* to have been different, as
well. The release-2 version should have said:

prev: 4.32.7-2
curr: 4.32.7-10 (not -3).

> Since release-2 isn't supposed to have obsolete stuff in it can't we
> just remove this directory entirely?

No.

How do you propose to accomodate people -- esp. testers who have
accepted Corinna's plea to "please begin testing cygwin-1.7" -- that
have an existing "lzma" package into their cygwin-1.7 installation? 
They need to (automatically?) get that existing one removed and the new
version from xz installed in its place (ignoring the fact that I screwed
up the setup.hints -- TWICE -- this time).

Is the policy about obsolete files so hard-and-fast that we want to
require current 1.7 users to manually perform these actions, "uninstall
lzma and then install xz..."?

Ditto for the reorganization of the libpng packages. It wasn't enough,
in that case, to just update libpng12-*.  Because I was ripping out the
alternatives support, I needed to force an update of both package sets,
even though libpng10-devel was moved obsolete.  If I had just deleted
the libpng10-devel directory, then folks would have been left with
"half" of the alternatives system installed.  This would have broken
badly: only the "obsolete" version would have had an alternatives entry,
so alternatives would have tried to make it current by setting the
"symlinks" in /usr/lib/.  But, the "new" alternatives-less
libpng12-devel installed its actual files where alternatives wants to
put the symlinks.  It might work (maybe alternatives is shy about
deleting "real" files) -- but it would have been wrong, confusing, and
very ugly. (Note: at least THAT time, I didn't bork up the setup.hints).

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/