On Fri, 10 Aug 2012 05:04:40 +0000 (UTC) Duncan <1i5t5.dun...@cox.net> wrote:
> Michał Górny posted on Thu, 09 Aug 2012 22:47:38 +0200 as excerpted: > > > On Thu, 09 Aug 2012 22:30:02 +0200 Luca Barbato <lu_z...@gentoo.org> > > wrote: > > > >> On 08/09/2012 09:43 PM, Michał Górny wrote: > >>> On Thu, 09 Aug 2012 10:42:15 +0200 Luca Barbato > >>> <lu_z...@gentoo.org> wrote: > > >>>> [W]e could discuss about why reinventing shellscript may > >>>> not be that sound and other less glaring, horrid and > >>>> appalling design choices. > >>> > >>> Yes, exactly. So why does openrc reinvent that horrible > >>> shellscript? > >> > >> It is not re-invented, in fact we can use any compatible shell. > > > > Or anything else what can be spawned for shell. And a lot more what > > you won't expect. And guess what, people are actually doing crazy > > things with it because someone forgot to tell them how a init.d > > script should work. > > Sounds interesting. A couple quick links to examples of what you had > in mind would be nice. =:^) > > (Or a bit more description, enough to both get the concept and google > with would be good, but links could be quicker if you have them > handy, and are less likely to spawn even further afield subthreads.) vdr is a first example which comes to my mind. They workaround program configuration limitations and the init.d scripts become a complex extra-configuration parser + plugin loader. Well, another thing here is that upstream AFAIK is not willing to cooperate to fix their config parsing. 'oldnet' is an another example. I'm not saying it should go; I'm saying it should be a stand-alone executable called from the init.d script. Last time I looked, squid init.d was performing post-inst in start(). Many users may find that beneficial but that's not what init.d scripts should be doing. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
