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

Wichmann, Mats D mats.d.wichmann at intel.com
Tue Apr 3 17:11:10 PDT 2007


> on my work on the LSB DDK (Driver Development Kit) I have
> found out that the LSB lacks standard calls for system 
> setup tasks which can be used from package maintainer 
> scripts for example.

Thanks for your comments, Till. This general class of
issues is pretty well known but hasn't gotten a great
deal of traction.  It really helps to have the feedback
from someone actually trying to put together conforming
packages. 

> For printer driver packages and also the CUPS package I need:
> 
> - Adding and removing startup scripts for system service
> For this there is /usr/lib/lsb/install_initd and
> /usr/lib/lsb/remove_initd. We need to assure that all distros ship a
> working implementation of it. 

We actually have tests for it (also need to check for the
presence of /lib/lsb/init-functions).  It's been put on the
"must" list to get those tests integrated into production
as at the moment they're sitting (uselessly) in version 
control only.

> - (Re)starting a daemon
> Must be done both for a daemon of the package itself (for example a
> daemon which is part of the printer driver, like the daemons of HPLIP)
> and for daemons of other packages (CUPS needs to be restarted after
> adding or modifying files used by CUPS). For this LSB does not provide
> anything. 

I think as people have discussed right now we're stuck with
"reboot", which really is pretty weak.  The init-script
commenting scheme describes a way to express dependencies,
and also required commands, like restart, but there's no
runtime component - there's no way to say to restart, for
example.  It's implied that you can call the script and
give it the restart argument but even that is not strictly
true, for example on debian systems you're not supposed to
(although it still may work) call the scripts directly,
but to use invoke-rc.d.  There's been the beginnings of
a proposal to add some command like that to LSB. That 
should be further pursued.

> - There is no command to link PAM config files into the PAM
> config directory

Yes, true.  The PAM work to date only describes the programming
API, but not configuration files or modules.

> - Is "/sbin/ldconfig" for registering dynamic libraries standardized?

No. Your'e stuck with the other mechanisms, such as -rpath when
linking or LD_LIBRARY_PATH.

> - 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.


> See also the ugly maintainer scripts needed due to this:
> 
> http://www.linuxprinting.org/download/printdriver/SPECS/cups.spec
> http://www.linuxprinting.org/download/printdriver/SPECS/ghostsc
> ript.spec
>
http://www.linuxprinting.org/download/printdriver/SPECS/gutenprint.spec
> 
> I am also considering adding RPM macros for typical tasks to
> be done by the maintainer scripts, especially also to make it
> easier that they work in both RPM and DEB packages.




More information about the lsb-discuss mailing list