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

Till Kamppeter till.kamppeter at gmail.com
Wed Apr 4 11:34:25 PDT 2007


Wichmann, Mats D wrote:
> 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.
>

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

Other problem is inconsistent naming of init scripts. Debian folks have 
renamed cups to cupsys. Does someone know why? Should LSB introduce 
standard commands to restart daemons? For example "daemon-restart 
printing" could restart whatever printing system the distro uses: cups, 
cupsys, lpr, ...

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

The config handling should be added to LSB, too.

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

For now I am ovoiding to provide shared libraries with LSB packages 
(only static libraries and static linking), but it would be nice to be 
also able to provide distribution-independent library packages.

For drivers to be suppled in shared library form (OpenPrinting 
Vector/OPVP interface) the GhostScript path in the PPD file will be 
preceeded by an appropriate 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.
> 

So then that is perhaps a bug in the build environment and the sample 
implementation.

    Till




More information about the lsb-discuss mailing list