On Sat, Jul 08, 2000 at 01:16:42AM -0400, Christopher W. Curtis wrote: > > Why do you feel this way? A lot of the debain scripts contain stuff > which seems non-obvious to me, and they (pretty much) all do the same the majority of debian initscripts are elegant in their plain simplicity. its very obvious exactly what is occuring and its very clear how to make changes (say add a command line argument) > few basic things: start programs, stop programs, and display messages. > Why is it wrong to combine these? because not all daemons are alike, each has thier own subtle needs, trying to make a one-size-fits-all shell script `library' will only cause bugs, and make the script less clear and harder to modify. instead of just adding a command line argument i now have to go read though some mess the script sources and figure out how these functions like reinvent(wheel) work. this is exactly why i hate redhat and eschewed it from everywhere i work. tell me why it is somehow more desirable to have: generic_kill() `pidof sshd` instead of say: kill -15 `pidof sshd` or killall sshd or start-stop-daemon --stop --quiet --exec /usr/sbin/sshd > Furthermore, making it a policy to source one config file (it should be > two - one default, one user override) to read a bunch of environment why? > variables would make a lot of the scripts even more confusing/convoluted > then they already are. That just doesn't seem like a good thing(tm) to > me. then perhaps we should forget the entire enterprise. your method makes things FAR more convoluted and complicated then a couple simple variables will. i am still not entirly convinced the config.d idea is a good one anyway. if it is to turn into a redhat mess of twisted functions like you propose then i am 210% against it. and will switch to slackware or *BSD if debian actually loses their mind and does it. > Look at the tarball I sent as a followup - it's really not that > complicated, and it can still be up to the script writer to chose to use > it or not. I have a total of five functions: start(), status(), > generic_kill(), then hup() and usr1(). The only other thing that I can > see wanting to be added is more signals - eg, kill(), and usr2() - and > these constitute a mere 5 lines of code each, including comments. i still hate it, sorry. > > [snip obfuscated ball of redhat spaghetti] > > Come now - I've had to deal with RedHat init scripts and this is nothing > like them (nothing like the ones I had to debug in 4.2 or 5.2, anyway). > One sourced file from the init script. That file sources a default and > user option file sitting in defaults.d/packagename. The goal is that > these files are the real variables, and nothing more. Sourcing the > 'defaults' file simply handles it for you, adds a couple extra checks > that would have to go into the script anyway, then provides a few > functions which I think should be encouraged but which need not be used. just like great ol redhat... i think my vote is going towards abandoning the entire config.d idea now before it turns into the festering boil of a initscript system that is redhat. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpx7g2tq1RgQ.pgp
Description: PGP signature