Re: timezone -> timezones (why?)
On Mon, 23 Feb 1998, Santiago Vila wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> On Mon, 23 Feb 1998, Dale Scheetz wrote:
>
> > On 23 Feb 1998, Kai Henningsen wrote:
> >
> > > (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?)
> >
> > My main argument for not changing this nit is that the autoup.sh script
> > has already been changed to accomodate the name/essential changes to
> > timezones, so what is the point of falling back to a second solution?
>
> Not every user will use autoup.sh.
> I, for one, will use pkg-order.
There is a clearly defined path to an upgrade. If you choose to deviate
from that path, it is your responsibility to know what you are doing.
>
> The solution of keeping the name untouched is cleaner, because an empty
> package (timezone) removed but not purged is a potential risk.
>
This is a problem for any package that changes its name. The fault is with
the way dpkg handles that transfer, leaving dangerous scripts available
for use and encouraging that use by how it flags the Replaced-Conficted
package in the status file. Removing all records of the replaced package
in the dpkg database would be a much safer/useful way to deal with package
replacements (i.e. renamings) than the way it is done now.
> However, if you insist on not changing package name (i.e actually
> *changing* it from bo to hamm), then at least please do the
> following:
>
It has been called timezones for as long as I have maintained the package.
While that hasn't been a long time, I have a different attitude than you
and others about how to maintain a new package.
When I came to Debian (and since then) it was my approach to learn how
things were done, and learn to use the tools provided to do things the way
it had been designed to work. I see many new maintainers who come into the
group and immediately set to work "fixing" all the things that are "wrong"
with the way Debian does the job of distribution creation. From our past
discussions it appears that you are a "fixer" while I am a "opperator". I
prefer to work with things as they are and not do redesigns without
plenty of understanding.
I am currently not sufficiently convinced that what you wish is correct to
modify the current functioning of the timezones package.
> Create a dummy timezone_99 package (section oldlibs) with no conffiles at
> all, and make the new timezones to conflict with the timezone in bo (but
> not with the dummy one). I'm sure autoup.sh can manage that.
>
> This way people using autoup.sh will be happy and people using pkg-order
> will be happy too, since they will be able to purge the dummy timezone_99
> without removing the configuration file /etc/timezone.
>
> Also, please, do not make /etc/timezone a conffile in the new timezones
> package, because according to dpkg's packaging manual:
>
> 9.2 Fully-featured maintainer script configuration handling
>
> For files which contain site-specific information such as the hostname
> and networking details and so forth, it is better to create the file
> in the package's postinst script.
>
> [...]
I'm not sure what this has to do with /etc/timezone. This file is handled
both in the postinst and using dpkg's conffile feature. From what I can
tell, looking at the scripts, the use of the conffile is to keep the
package from needing to be "configured" every time it is upgraded. I'll
look into this more at some point and see if there is a better solution
using only the postinst script, but right now I don't have the time.
>
> We have many different timezones, so it will be very unlikely that you
> will find a "default" one that satisfies everybody.
>
No, but once the file has been set by the sysadmin it is desired that it
remain constant through upgrades. I suspect that the script writer saw the
conffile as a good way to manage this problem.
> Consider that this is a similar case to /etc/papersize or /etc/gpm.conf
> (which are configuration files, but not "conffiles" in the dpkg sense).
>
I can see your point, I just don't see any reason to change what works
simply because you don't like the idea of using conffiles.
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: