Re: timezone -> timezones (why?)
On Sun, 22 Feb 1998, Santiago Vila wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> [ moving to debian-devel, from debian-bugs-dist ]
> Summary: I think timezones package should be renamed back to "timezone"
> (i.e. timezone package should *not* change his name from bo to hamm)
> while Dale Scheetz does not agree.
What Santiago fails to mention here is that the reason he wants it changed
back is to accomodate an upgrade directly from rex to hamm.
The difficulty arises in the first place because the rex timezone package
was marked essential. The bo timezone package removed that essential flag
and upgrades fine. The name change between bo and hamm cause no problems
for that upgrade path either.
It is only a problem for upgrading from rex to hamm, and that has already
been taken care of by the autoup.sh script, as I understand it.
> 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
> do not work, file a bug report. They work for me, and they should also
> work for you. The current dpkg in bo and hamm *supports* epochs.
While this "may" be true (I remember bo still having some problems, but
they could have been fixed by now) the problem lies with rex and I know
that it's dpkg didn't support epochs. Even though dpkg will need to be
upgraded, and can be under special situations, the existance of the epoch
marked packages in the packages file was enough to break older versions of
Only considering this point, it just doesn't seem to me that the payoff is
worth the cost. I see this as simply moving a well known problem into a
different, less well known problem.
> But a change in the package name is currently gratuitous. It creates more
> problem that it solves.
I obviously don't agree. The packaging system should be able to deal with
package name changes properly, and currently it doesn't.
For me the bigger problem with changing the name of a package (and this
applies to more than just the timezone/timezones package) is the fact that
dpkg/dselect leave the status file in a state where a purge can be
performed on the Replaced/Conflicted old package name that will execute
postrm scripts, allowing the old, removed, package to break the new one by
removing its configuration files in postrm.
> Is the usage of epochs the only "problem"?
I don't know, I didn't make the decision to rename these packages.
I am a bit concerned at your focus on this relatively minor nit, that has
been dealt with in other ways. It appears that your insistance comes from
a belief that any previous Debian package should be upgradable by any
future version of the package. You seem to think that if it can't, that it
is the fault of the new package and that accomodation to the old package
is absolutely necessary. While this is a desirable goal, it is not a
necessary one, specially during this difficult transition to glibc.
In this case there *is* an upgrade path. It goes from rex to bo to hamm
with no problems, and it can go from rex to hamm with a force option.
As a new maintainer of an important package, I am still at a stage where I
am unwilling to second guess the previous maintainer's decisions. Mostly I
don't see this as the giant problem that Santiago perceives it to be.
_-_-_-_-_-_- Author of "The Debian User's Guide" _-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: firstname.lastname@example.org Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .