Re: libc6_2.0.7 release notes...
Dale Scheetz <dwarf@polaris.net> writes:
> Everyone doing an upgrade this go 'round is going to have to be appraised
> of the packages to install "by hand" in any case, so this doesn't "add"
> another step, it just uses the step we are already being forced to take,
> as a way to avoid additional mess.
Not if they use autoup.sh or apt, but I suppose that the readme that
tells them about that could also mention the libc6 problem.
Regardless, the 2.0.7r thing seems OK (though it's somewhat a matter
of which bugs you more X:version or 2.0.7r), so much of the rest of
this is just academic.
2.0.7r makes this irrelevant now, but one other consideration would
have been all of those who have been following unstable or frozen and
have already "upgraded" the other set of "by hand" packages. How
would you make sure they bother to read a README that appears to cover
things they think they already did?
And I'd really rather not have to remember to upgrade libc6 manually
on 7 different machines at 3 different locations when my next dselect
run could have just "remembered" it for me. I'm sure it's even more
annoying for people with more machines. "By hand" upgrades are a
failure point we shouldn't create when we know how to avoid it.
> There has got to be a better way to deal with this problem (which is
> fundamentally a sorting problem).
We can't cover all cases without something like epochs if we're going
to allow the upstream authors to choose their version numbers. Heck,
some loon could choose something like:
1.0-good
1.0-better
1.0-best
For this reason the suggestion that we just make dpkg understand pre,
alpha, beta, etc. is doomed to failure. And, of course, instead of
alpha and beta some just use a and b. I've even seen gamma, and I
know one organization that uses GM for (Golden Master) as the final
release candidate.
> What we need here is a better way of dealing with this problem. My mind
> has no solution at the moment, but my gut says that there is one, so I
> will keep looking.
Good luck. It would be great if you come up with one, but I fear it's
going to be a lot of work for essentially a *really* minor aesthetic
gain.
One way this could almost be handled is with and additional control
file where you could list sort exceptions. Something like this:
2.0.7pre1 < 2.0.7
2.0.8pre7 < 2.0.8
etc. This file would allow each discontinuity to be specified, and
would be pretty flexible, but it still has the problem (that epoch's
don't) that if the upstream authors do something really weird you're
still out of luck. The problem is that these rules aren't (time)
context sensitive.
Consider some author releasing:
2.0
2.1
3.0
1.0
2.0
This is essentially a version renumbering (perhaps to match some other
package, or whatever). In this case, the exceptions list wouldn't
help because you'd still think the later 2.0 was equivalent to the
earlier 2.0 if. Here, something like epochs are needed.
> The reason I think this is a continuing problem is that the next
> round of glibc development is just a likely to run through several
> "preX" versions before a release is made. There is a strong
> advantage in our participation in the testing of these pre-releases
> (just as our users gain benefit from pre-release testing of
> packages). I would suggest that we would not have a 2.0.7 to be
> arguing about if we had not used and reported problems with the
> pre-release versions. What we need is a way to use these pre-release
> versions without having their version numbering effect the archives.
Oh, I don't think anyone's arguing against that, but if it were up to
me, I'd just say we should use epochs and get on to more interesting
problems.
> In the mean time, unless anyone can object within the next several hours,
> I will construct and upload a new release of glibc with the version
> number: 2.0.7r-1
Sounds good.
--
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: