Re: timezone -> timezones (why?)
dwarf@polaris.net (Dale Scheetz) wrote on 22.02.98 in <[🔎] Pine.LNX.3.96.980222142555.260A-100000@dwarf.polaris.net>:
> On Sun, 22 Feb 1998, Santiago Vila wrote:
> > On Sun, 22 Feb 1998, Dale Scheetz wrote:
> >
> > > David chose to rename both timezone and locale because of a version
> > > number setback. The libc6 versions of the packages carry the version
> > > number of libc6, which is less than the version numbers of the old
> > > packages. Without renaming the packages, they would represent a
> > > downgrade of these packages, raising difficulties for their "upgrading".
> > >
> > > Epochs are supposed to deal with these kinds of problems but both David
> > > and myself are not comfortable with this "functionality", as it hasn't
> > > worked as expected, so far.
> >
> > Could you please elaborate on "not work as expected"? If you think epochs
>
> This was David's decision and I am not willing to second guess that
> decision.
I am.
The problem with epochs and a dpkg version that doesn't support them was,
once dselect _sees_ packages with epochs, it breaks.
The trouble with using that as an argument against using epochs is simply,
_one_ package using epochs in the distribution is enough to trigger that
bug. We already have more than one.
One more epoch'd package won't make a difference.
The argument was valid when that problem first occurred, but today it's
completely bogus.
(Actually, it points us at something completely different: the autoup
script should be able to deal with a epoch-corrupted dpkg database. ISTR
all that was needed was dpkg --clear-avail [then dpkg -i dpkg, of course]
- is that right?)
MfG Kai
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: