> > 	2)  those who modify this behavior do so at their own risk
> > 	    and knowledge that packages will likely not install
> > 	    correctly for them.
> 
> So what you're saying is, everyone who didn't like /etc/init.d in the
> previous discussion doesn't need to use it, except that things won't
> work for them.

They'll work no worse than packages trying to automatically add things
to /etc/rc* work now for most people.  Simplify the common case, make
the people who want the uncommon case pay extra effort for it.


> Look, either address all the arguments we made in the previous round
> of discussion (/etc/init.d is messy, difficult to understand, uses
> alphabetical ordering of symlink names in a manner resembling BASIC
> GOTO statements to store configuration information, and does this all
> to simplify exactly one operation, when there are plenty of other,
> better ways to do that), or don't ressurect the argument at all.
> 

In my opinion, about your parenthesized points:
(1) is false, (2) is false, (3) is a feature, and (4) i've yet to see
any better proposals about how to do it.

doing a topological sort at boot time is right out, in my opinion, as
is using a special utility (which may or may not do such a sort) when
setting up init.d.  They're just _not_ acceptable, because the former
can potentially cause hard-to-diagnose losing behaviour without the
sysadmin being easily aware of it, and the latter because it means
that you can't easily modify init.d's contents w/o the utility.


Existing 'init.d' mechanisms work well, for a large number of
commercial, research, and home users.  Why screw with them and come up
with something new, weird, and potentially harder (or even, depending
on your system's environment and what new commands are required,
impossible) to use?


cgd