lsb for Debian -------------- This package provides the Linux Standard Base on Debian systems. The LSB is a specification for allowing the same binary package to be used on multiple distributions. INSTALLING LSB PACKAGES The "alien" package supports LSB packages on Debian. For example, to install an LSB package "lsb-mozilla-1.2-1_i386.rpm", type (as root): alien -i lsb-mozilla-1.2-1_i386.rpm Ideally, the package should be converted to a Debian package and then installed by dpkg. If this fails, there may be a problem with either the lsb package (most likely) or alien (less likely), and you should contact the vendor of the lsb package to resolve the problem. PACKAGE LAYOUT The LSB implementation in Debian is currently divided into eight packages: * The "lsb-core" package depends on the Debian packages that are required to comply with the LSB-Core 3.2 specification; this is roughly equivalent to the LSB 1.3 specification, except X11 libraries are not required. It also includes some subroutines that are used by LSB-compliant applications when they are being installed or removed. * The "lsb-graphics" package depends on the X11 libraries required for the LSB-Graphics 3.2 specification. * The "lsb-cxx" package depends on libstdc++5, required for the LSB-CXX (LSB-C++) 3.2 specification. * The "lsb-desktop" package depends on the Gtk+ and Qt libraries required for the LSB-Desktop 3.2 specification. * The "lsb-qt4" package depends on the Qt version 4 libraries required for the LSB-Qt4 3.1 module. Note that this module is essentially folded into lsb-desktop for LSB 3.2 and above. * The "lsb-languages" package depends on Python 2.4 and Perl 5.8.8 or later. * The "lsb-multimedia" package depends on libasound2. * The "lsb-printing" package depends on the CUPS libraries (libcupsys2 and libcupsimage2), foomatic-rip, and Ghostscript. * The "lsb" package depends on all of the above packages, and exists for backwards compatibility purposes with LSB 1.3. * The "lsb-base" package includes a number of functions used by init.d scripts in some LSB packages; this package was separated in Debian's lsb 2.0-6 package so other packages could make use of the init functionality without requiring a full LSB installation. For documentation of those functions (and those added for Debian's use), please see the README.Debian file in that package. * The "lsb-release" package includes the lsb_release command, which provides information about the installed LSB modules and the underlying distribution. The LSB module packages are architecture-specific because of differences in the requirements of the LSB on various binary architectures. In particular, each package provides lsb-{module}-noarch and lsb-{module}-{arch} virtual packages. IMPLEMENTATION ISSUES This package attempts to implement the core LSB specification. Much of the implementation is drawn on a talk by Wichert Akkerman (http://www.liacs.nl/~wichert/talks/LSBDistro/html/) and Matt Taggart's discussion of LSB 1.0 and Debian. Matt has also produced a slideshow on LSB in Debian, which can be found at: http://people.debian.org/~taggart/debconf2/ This package implements the LSB specification by: - depending upon packages that implement OS services required by the LSB, including libraries and programs. - including the correct symlink to the dynamic linker. - providing the LSB init script functionality. Some of the LSB init functionality cannot be implemented without cooperation from other packages or changes in policy for sarge+1; however, the remainder is provided here. The intent of this package is to provide a best current practice way of installing LSB packages on Debian using the Intel and PowerPC 32-bit architectures with the Linux kernel ("ia32" and "ppc32"). Its presence does not imply that I or the Debian project believe that Debian fully complies with the Linux Standard Base, and should not be construed as a statement that Debian is LSB-compliant. The specification is available at http://www.linuxbase.org/spec/ DEVIATIONS FROM LSB The package and its dependencies implement all of LSB on Debian, with these exceptions: - LSB 3.2 assumes a 2.4 or later kernel. Debian ships a 2.4 kernel by default on most architectures as of sarge, although 2.2 and 2.6 are optional. There is no way in the Debian system to ensure a package is only installed on a specific kernel release. Running LSB applications on 2.2 kernels may result in subtle bugs or failures, particularly if they depend on large file support or new syscall interfaces introduced in Linux 2.3+. (We do not consider this a bug in the package.) - LSB 3.2 doesn't fully specify what the init_functions should do. I have chosen to implement them in a way that is consistent with Debian current practice, using the start-stop-daemon utility and the echo command. For sarge+1, I expect a nicer init logging facility that could be used. - LSB specifies no way for a binary to request that a pid file be created for it, and the spec is ambiguous about whether start_daemon should create the pid file, therefore I assume the binary will produce its own /var/run/basename.pid file. - Debian only implements certain features of adduser if shadow passwords are enabled. The lsb package will prompt the user to enable shadow passwords if they appear to be disabled; however, it does not force this choice on the administrator. Administrators who disable shadow passwords may find that some LSB applications fail to operate correctly as a result. (We do not consider this a bug in the package.) - The LSB specifies that several X libraries must be available on the system, but does not specify the presence of either an X server or any X clients. However, many LSB packages may expect these things to be present, despite their absence from the spec. Similarly, the printing specification requires the CUPS libraries but no CUPS binaries; hence, printing may be impossible unless you actually install the cupsys package. (This may be a deficiency in the spec. However, we comply as-written.) - The LSB specifies that cron scripts can be placed in cron.daily and other directories; however, Debian's run-parts appears to ignore these scripts if they contain a dot in their names. (See #118646) You can work around this problem by editing /etc/crontab and specifying the --lsbsysinit option; it is hoped that eventually Debian will include this option by default. (This is a known deficiency in debianutils, and is required for backwards compatibility with expected behavior on earlier systems.) - /etc/profile.d scripts aren't executed on shell startup by default on Debian systems (see Debian Policy section 9.9 for an explanation). LSB 3.2 is ambiguous on this requirement; /bin/sh is *not* required to execute these scripts, according to its description, but the lsbinstall documentation says that it is. Debian policy forbids the use of /etc/profile.d by Debian packages, so it is unlikely this will change (as it might be seen as encouragement for Debian developers to do use it.) There may be other deviations from the spec; they are bugs in this package and should be reported as such using Debian's bug tracking system: see reportbug(1) or your favorite bug reporting tool. (The aforementioned deviations are generally bugs in the package that cannot be easily fixed, or are bugs in the specification itself that we hope to resolve in the near future.) For more discussion of these deviations, see: http://lists.debian.org/lsb-spec/2001/lsb-spec-200107/msg00002.html (a discussion of deficiencies in LSB 1.0, mostly resolved) DESIGN DECISIONS - I implemented the LSB init dependencies based on Debian policy's update-rc.d support. A registry of package-provided facilities and their start and stop priorities is retained in /var/lib/lsb/facilities. Priorities are assigned to the system facilities as found on my sid systems as of today; perhaps system facilities should be registered by the appropriate packages, and not managed by the lsb package, but that is a sarge+1 policy decision. - As of 1.3-1, a second registry of init script dependencies is retained in /var/lib/lsb/depends. This is used to ensure that an LSB package will not be removed if it provides an LSB facility that is used by another LSB package. (If you rely on this functionality and are upgrading from the 1.2 series, you will need to manually reinstall all of your LSB packages.) - As of 3.0-2, a third registry of files installed by lsbinstall is retained in /var/lib/lsb/lsbinstall. Unlike the other two registries, it is not designed to be human-readable. - The facility handling scripts are written in Python. I am not particularly attached to them being written in Python, but at the same time I do not forsee rewriting them in $language_of_choice. COMPLIANCE TESTING I have been unable to locate any LSB package that tests the init script functionality of the spec. I am therefore unable to say whether this package actually works as advertised. I would appreciate any reports of its success or failure. An example init script that tests some of these features is provided as /usr/share/doc/lsb/examples/init-skeleton. -- Chris Lawrence , Sun, 2 Mar 2008 02:20:47 -0600 LocalWords: LSB