Re: request for a init script policy
Today, Ethan Benson <erbenson@alaska.net> wrote:
> On Tue, Jul 04, 2000 at 10:13:34PM +0200, Andreas Fuchs wrote:
>> can't work. config files are supposed to be modified by the user and
>> then left alone by dpkg and everything else or to be modified by
>> dpkg and then left alone by the user and everything else.
(subtle error in this one: I intended to say, "be left alone by the
user and then be updated by dpkg" in the second part)
> good point, though i have seen some packages do this i assume they are
> violating policy..
Uh-oh!
> how is /etc/network/interfaces handled? it is NOT a conffile but user
> configuration must be preserved..
dunno. This looks like aj's business to me...
>> rm -rf /$NEWVAR
> well any init script doing something like that is evil anyway...
Yes, but if it does something more suble than that, it can lead to
some errors that might be hard to trace. Imagine, a user upgrades lpd,
does not install the new configfile (ie, just presses return when
asked). After one or two months, the user tries to print a few
pages...
> debconf would seem to be the best solution, but things like comments
> really should be preserved.
Well, you could also store the comments (and also the
things-in-between-the-lines, but that would mean that you can't easily
use hashes any more. Would this structure work?
(stuff-between-last-valid-and-this-line, match-nr, value-of-variable)
the key to the hash is the name of the variable.
Then, output the lines in order of match-nr, ascending. This looks
like it is not going to be very beautiful.
Thinking about it, there are also other things that could happen,
instead of the maintainer introducing new variables:
1. old variables could be removed
2. the meaning of the variables could be changed
3. variables could be renamed
4. both 2.&3.
This looks quite nontrivial to me. Uh-oh!
> if this config file cannot be handled perfectly its not worth doing
> IMO. (meaning i would rather deal with upgrading a single modified
> script (the initscript) then an initscript and a initconf)
Maybe drop the whole error-prone behavior and have dpkg only issue a
warning if the new (original) initconf changed from the previous
(original) version?
The user will most likely have modified the initconf, so the original
versions of both files must be compared (checksums?)
>> That was not dope, that was me having only just crept out of
>> bed. Anyway, what be da difference, man? (-;
> i dunno, i think redhat's mess had to be induced by something more
> potent then lack of sleep. ;-)
*G* Swallowing magic mushrooms again, eh, Mr. Hat?
regards,
--
Andreas Stefan Fuchs in Real Life aka
asf@acm.org, asfuchs@gmx.at, asf@ycom.at in NNTP and SMTP,
antifuchs in IRCNet and
Relf Herbstfresser, Male 1/2 Elf Priest in AD&D
Reply to: