[lsb-discuss] More standard calls for system setup tasks needed inthe LSB

Wichmann, Mats D mats.d.wichmann at intel.com
Wed Apr 4 11:57:16 PDT 2007


> Daemon-restarting with
> 
> /etc/init.d/<name> stop
> /etc/init.d/<name> start
> 
> should work on any distro, as LSB at least requires the
> scripts being in /etc/init.d/, only that LSB packages will
> not follow the Debian policy then (does someone know what 
> can break on Debian when calling the init scripts directly?). 

LSB-conforming initscripts must also accept the
restart, and force-reload arguments.

...

>>> - Directories /opt, /etc/opt, and /var/opt should exist in an
>>> LSB-compliant distro, so that packages installing into /opt can be
>>> installed without "--nodeps".
>> 
>> They should exist; I don't know if the tests test for /etc/opt
>> and /var/opt.  But packages with those paths should still install.
>> 
> 
> So then that is perhaps a bug in the build environment and the sample
> implementation. 

I think it is.  The relatively recent version of rpm that
went into both suddenly requires every directory you install
into to have an owner (as in, a package that "owns" it).  Because
of  the way at least the sample implementation is built, the rpm
database does not think it owns anything in the system, as
it's not an rpm-based install.  If you explicitly list those
directory names in your package files list it ought to work,
but might later conflict with other packages that way.  That
rpm change appeared very suddenly, and I think we have a bug
on creating a dummy rpm for the filesystem heirarchy and
installing it so the rpm database knows about those. It's
kind of an irritating change because it makes it very 
difficult to use a system where rpm is the add-on package
manager, but the system itself is not rpm-based (we inherit
this allergy to recent rpm from linux-from-scratch, we should
go back and see how they have handled it but I haven't
checked there for quite a while)




More information about the lsb-discuss mailing list