Re: RFC: A method to use Admin tools, like linuxconf
Hi,
Nice summary, Andreas. I agree about saving the values for
variables used by the {pre,post}{inst,rm} scripts and runtime scripts
somewhere. (I think that there is an overlap here -- data gathered
from the human installer is often used by the run time scripts later,
makes sense to have on consistent database). BTW, the database should
be accessible by means other than a special tool -- just think
windows registry.
I don't understand why you mentioned the SysV init links, yes,
a file will be easier to manually edit (all the data is in one
place, one may use the one true editor, etc), but it becomes a
nightmare for programs (install scripts as well as config/admin
tools) to edit in place, the symlinks are well understood, and easy
to manipulate.
You should decide what you want: a config admin tool (in which
case use whatever backend is easier for programs to deal with; as
long as there is a means of bypassing the program), or go for ease of
use for the human, which is slightly subjective (this particular
human likes using, ls, find, pushd etc, more than the nightmare
rc.local had become on my ultrix boxes).
Believe you me, ``nice'' config files are a honey trap, they
tend to grow more and more convoluted, and un manageable, as time
goes on. (One of the reasons DEC moved to symlinks and removed
rc.local with Digital Unix, good move, IMHO).
I think that removing the separation we have achieved with
SysV init and going back to giant rc.local is a big mistake, and will
make it impossible for non unix experts to run a Debian system. I
don't think it is as trivial to edit a file in place as you think,
and one error will hose the system. (ever lost a rc.local on a
network server, with the backups on a node across the town?)
Aesthetically, init.d and symlinks may not be pretty, but they are
robust.
A gui will take the tedium out of adding and removing link, a
user friendly update-rc.? will make it accesible from the command
line, or else there is always ln and rm. (IMHO, ease of editing a
config file does not outweigh the greater fragility of the new
system).
I do think, though, the points about less than perfect
behaviour of scripts in init.d were valid: maybe we should have each
script just start one daemon, unless the daemons are so closely
related they won't function individually? (give finer granularity to
tuning the site -- Policy manager?)
I disagree that we do away with scripts that merely call
start-stop-daemon: don't break what is not broken.
Oh. I think that adding greater robustness to init such that a
hung script does not kill init may be decent -- run all scripts in
the child, and catch retuen status.
manoj
--
"With molasses you catch flies, with vinegar you catch nobody."
Baltimore City Councilman Dominic DiPietro
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: