Re: libc6_2.0.7 release notes...
On 22 Jun 1998, Rob Browning wrote:
> Santiago Vila <sanvila@unex.es> writes:
>
> > But I believe that most of our users will agree that 2.0.7-1 is a much
> > nicer version number than 2.0.7r-1 and would not mind to install a few
> > packages by hand just *once*.
>
> I don't agree. We have a mechanism to allow clean upgrades. We
> should use it, and we should either change policy to not discourage
> this, or we should come up with an alternate (but most likely
> identical) mechanism for this purpose.
I agree in general, but not in this specific case.
>
> Which is better for the user, a README somewhere that they have to
> read (presuming they actually realize that) and upgrading by hand, or
> an epoch number that they'll probably never see, and an automatic
> upgrade?
>
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.
> Being aesthetically opposed to epochs to the degree that you're
> willing to force the user to upgrade manually seems unsupportable to
> me.
Policy says I should not use epochs to resolve prelease numbering
problems. (So what good is this thing anyway?)
Phil's suggestion that this "uggly" epoch implicitly exists on every
package version. I'm not sure I like the distinctive clutter that that
will impose on a Debian distribution.
There has got to be a better way to deal with this problem (which is
fundamentally a sorting problem).
Santiago's suggestion of 2.0.7r-1 is more satisfying but, if you consider
the situation, doesn't really resolve the long term problem any better.
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.
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.
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
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: