[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: request for a init script policy



On Tue, Jul 04, 2000 at 10:40:57AM +0200, Andreas Fuchs wrote:
> 
> On 2000-07-03, Ethan Benson <erbenson@alaska.net> wrote:
> > the only request i would made of this is that these config files be
> > JUST config files, nothing in them but a couple variables.  please
> > don't go running out of control like redhat and have dozens of scripts
> > full of functions sourcing yet other scripts with functions creating a
> > massive ball of spaghetti...  
> 
> Hm. What if functions themselves could be customizeable? I know that
> redhat's scheme is quite complicated, and I wouldn't recommend debian

s/complicated/convoluted|obfuscated/

> to do it the same way. But think emacs's hooks: What if the user could
> specify a function (start_hook?) that should be run before the script
> checks for start/stop/restart cmdline options or a function that is to
> be run after the daemon starts (daemon_started_hook?) etc?

i think this is asking for trouble....  (read obfuscated horrible
redhat mess) 

init scripts are supposed to be simple, remember the good old unix
tradidtion of `do one thing and do it very very well' ?  initscripts
should do one thing: start and stop services|daemons.  thats it.

> If these things could be moved to a seperate file, you could reduce
> the times users have to edit the init.d script by hand even more, thus
> saving them even more hassle with customized init.d scripts.

im sure that was what redhat was thinking, now you can't edit thier
scripts at all since nobody can figure out how the damn things work.
(you spend hours chasing sources and includes all over the damn place
going in circles all the way.)

> > and even if the init.d script have a seperate file to configure them,
> > the init.d script itself must remain a config file to dpkg.  
> 
> As must the seperate file itself. What if the maintainer chooses to

that is a given.

> introduce some new variables? Maybe debconf could solve this, though I
> don't know how.

since they should be nothing more then shell variables he can just
append the new varables to the config file i suppose.  i don't think
such a configuration system should be any more complicated then
VAR=foo type variables.  you want anything more complicated (functions
et al) please switch to redhat and leave us alone ;-)

> Anyway, it _is_ a great idea.

lets just not smoke too much dope and get carried away like someone
else i may have mentioned.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgp_wrBJMrFjn.pgp
Description: PGP signature


Reply to: