Re: Naming of init.d scripts and the LSB

[Matt Taggart <taggart@debian.org>]

Steve Langasek writes...

> That's a fine goal, but I believe it's out of scope for the LSB, and I don't
> want to see the ability of distros to conform to the LSB compromised by some
> poorly designed attempt to enforce common init script names.

As I pointed out in another mail, the LSB can't mandate this due to it's 
trailing edge nature. If someone could accomplish this goal *then* it would be 
in the scope of the LSB and could be added.

> The issue isn't even that the LSB mandates that distros use common init
> script names for particular services (it doesn't); the issue is that the LSB
> says that LSB packages are allowed to use any init script names that haven't
> previously been registered with LANANA.  There is no sane reason why a
> Debian packager should have to contact LANANA first for clearance before
> adding a new init script to his or her package; this is useless bureaucracy,
> offering no real advantages over requiring *only* LSB packagers to register
> with LANANA (which they'll have to do anyway).

Hmm, I just re-read

http://www.linuxbase.org/spec//booksets/LSB-Core-generic/LSB-Core-generic.html#
FHS-NAME-RULES

and I see the problem you are pointing out. I had assumed LANANA just dealt 
with the "lsb-" and "domainname-" but the above says it owns "[a-z0-9]" too, 
yuck.

Could we count on LANANA to not issue names that would conflict with existing 
distros in sort of a "prior art" manner? This would require a way to query all 
distro namespaces I guess (at least it's easier than a patent prior art 
search). I still don't like that though. It only fixes the problem of LANANA 
issuing something we're already using, and not the converse case, all new 
distro packages would need to check with LANANA to ensure they didn't conflict 
with something LANANA had handed out.

> > The same way, system administration tools, documentation and other
> > administration-related systems will be easier to handle for users and
> > system administrators if all Linux distribution have consistent naming
> > for init.d scripts.  I fail to see the advantage of reserving this as
> > a Debian namespace and consider the LSB as something we do not want to
> > use to create consistency across distributions in this area.
> 
> Frankly, I couldn't care less about cross-distro administration frameworks.

This isn't the LSB charter anyway. In the past I've considered the idea of an 
LSB-sysadmin standard.

 LSB = binary application portibility
 LSB-sysadmin = sysadmin portibility :)

-- 
Matt Taggart
taggart@debian.org