Dale Scheetz <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
