* Craig Small <[EMAIL PROTECTED]> [020505 20:19]: > I have got bug #138251 which talks about the init.d script and how it > is missing some nices things etc. > > Should Debian scripts be following the LSB and if so, why doesn't the > policy either mention the LSB or have the same standards? > > This is more important for me as the dh-make maintainer as a lot of > people use it to make their own packages so I like to get it right. > > I'm not on debian-policy, so please CC me.
I posted to the lsb-spec mail list and got some replies that are on target. I attached them below. Check the archives of those lists to see the full threads, but here are some key responses from Alan Cox and Ted Ts'o. Chris Lawrence did a better job doing a complete and accurate summary of the issue at hand than I did. So in short, I was wrong. Technically the init script LSB specifications are only applicable to lsb applications/packages. However the init script names must be coordinated as Ted mentions. I don't fully understand how this should/will function in practice. My thinking was from a user/administrator perspective such that all init scripts SHOULD have the same consistent set of functions. I was thinking that if they are defined clearly in the LSB we might as well use them. Yet this is a separate policy discussion that's beyond the scope of the LSB and goes to my personal opinions about possible future Debian policy. Cheers, -- -- Grant Bowman <[EMAIL PROTECTED]> On May 07, Grant Bowman wrote: > There's a discussion going on right now over on the > [email protected] mail list. I am looking for validation > in the specification itself that the LSB applies to systems as a whole > and not to only *.lsb packages. This seems like a crazy premise to me, > but I'm having trouble finding justifications in the specification to > clearly demonstrate otherwise. Any suggestions? * Alan Cox <[EMAIL PROTECTED]> [020507 15:35]: > Bit of both > > It applies to LSB compliant applications > It applies to the OS in the sense that it must provide LSB defined features > > There has never been any intent that it should apply beyond that * Chris Lawrence <[EMAIL PROTECTED]> [020507 13:49]: > Just to be clear, the debate is over whether distribution-provided > init scripts must comply with the Init Scripts section of the > specification. My and others' position is that there is no such > requirement, since LSB-conformant applications (as of LSB 1.1) cannot > depend on the presence or absence of any particular init script on the > system, so (a) they shouldn't care what command line arguments they > accept and (b) they shouldn't care what exit codes they return. > > Now, I don't think there is any disagreement that init scripts > provided by LSB-conformant applications must comply with the spec, as > the spec provides an interoperable subset of capabilities for init > scripts to use and an interoperable superset of command line arguments > for init scripts to function normally. > > (Having said that, I wouldn't be opposed to a requirement in the > future, if the interfaces were clearly defined and there was some good > reason for LSB applications to be mucking with init scripts provided > by the system... for now, though, that seems rather unlikely.) * Theodore (Ted) Ts'o <[EMAIL PROTECTED]> [020507 15:07]: > Yes, that's correct. The init scripts section of the distribution is > only applicable for LSB applications. > > In particular, the commenting conventions were designed only for LSB > applications. Attempts to generalize the Required-Start: headers, > etc. to work for all init scripts, including system header files, is > possible, but it makes the install_initd script far more complicated. > > The only thing which applies to system init scripts as well as the > naming convention. Here, distributions should register all init.d > script names that they use with LANANA, so that LSB-compliant > applications don't choose init.d script names which conflict with > distribution-provided init scrips. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
