Re: timezone -> timezones (why?)
On Tue, 24 Feb 1998, Santiago Vila wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> I'm going to summarize:
>
> I'm worried mainly by the fact that the old timezone has a "conffile"
> which could be removed if the user does "dpkg --purge timezone"
> after upgrading to hamm. The file /etc/timezone would be lost.
This is not what happens. It is the postrm script in the old package that
removes the fils that break the current timezones package. The fact that
/etc/timezone is a conffile is not relevent.
>
> [ I'm *not* worried by the fact that timezone was essential in rex ].
>
> The potential lost of /etc/timezone is a problem, and I think we should
> ideally have a general solution for it, not just a solution that works
> only when autoup.sh is used.
Autoup.sh does not, indeed, fix this problem. It only allows a rex to hamm
upgrade of timezones.
>
> I first proposed to keep the name of the package, "timezone", untouched.
> This would require an epoch, since the last timezone package was 7.55-2.
> [ Current source package for this is libc6, and it has 2.0.7 as version
> number ].
>
> The only problem with epochs is that they are "ugly", but they do work.
> However, since libc6 and the current timezones package both derive from
> the same source package, probably libc6 would also need an epoch. This
> would be perhaps the most ugly thing of all: Having a package named libc6,
> version 2.0.7, with an epoch value of 1...
>
> BTW: Question for dpkg hackers: Would be possible to have libc6_2.0.7
> and timezone_1:2.0.7 generated by the same source package?
> [ If not, I withdrawn from my proposal of keeping the name untouched ].
>
> The other solution I proposed is to create a dummy timezone package,
> version "99". This package would be completely *empty*, so that purging it
> would not remove any conffile at all.
>
> This would be also ugly, but once you upgrade to hamm, this package could
> be purged with no risk.
>
> If you propose a third solution (modifying dpkg so that it manages package
> name changes smartly), then go ahead, find somebody who implement that in
> dpkg in less than one month ;-)
>
> But please, don't tell me "everybody is supposed to use autoup.sh".
> Or "there is just *one* upgrade path". Our packaging system is robust
> enough to allow an upgrade of packages in a *random* fashion (if we use
> the appropriate Dependencies and Pre-Dependencies).
>
Your last paragraph here is completely off the track. Our packaging system
is not robust enough to support "random" package installation before the
critical packages have been upgraded. If Pre-Dependencies actually worked
in dselect there would be no problems with these critical packages, as
they would be assured of being there, but that's not how it works.
More than that, this issue has nothing to do with the --purge problem.
They are totally unrelated.
Later,
Dwarf
--
_-_-_-_-_ Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 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 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: