4 This package provides the Linux Standard Base on Debian systems. The
5 LSB is a specification for allowing the same binary package to be used
6 on multiple distributions.
8 INSTALLING LSB PACKAGES
10 The "alien" package supports LSB packages on Debian. For example, to
11 install an LSB package "lsb-mozilla-1.2-1_i386.rpm", type (as root):
13 alien -i lsb-mozilla-1.2-1_i386.rpm
15 Ideally, the package should be converted to a Debian package and then
16 installed by dpkg. If this fails, there may be a problem with either
17 the lsb package (most likely) or alien (less likely), and you should
18 contact the vendor of the lsb package to resolve the problem.
22 The LSB implementation in Debian is currently divided into eight
25 * The "lsb-core" package depends on the Debian packages that are
26 required to comply with the LSB-Core 3.2 specification; this is
27 roughly equivalent to the LSB 1.3 specification, except X11 libraries
28 are not required. It also includes some subroutines that are used
29 by LSB-compliant applications when they are being installed or
32 * The "lsb-graphics" package depends on the X11 libraries required for
33 the LSB-Graphics 3.2 specification.
35 * The "lsb-cxx" package depends on libstdc++5, required for the
36 LSB-CXX (LSB-C++) 3.2 specification.
38 * The "lsb-desktop" package depends on the Gtk+ and Qt libraries required
39 for the LSB-Desktop 3.2 specification.
41 * The "lsb-qt4" package depends on the Qt version 4 libraries required
42 for the LSB-Qt4 3.1 module. Note that this module is essentially
43 folded into lsb-desktop for LSB 3.2 and above.
45 * The "lsb-languages" package depends on Python 2.4 and Perl 5.8.8 or later.
47 * The "lsb-multimedia" package depends on libasound2.
49 * The "lsb-printing" package depends on the CUPS libraries (libcupsys2
50 and libcupsimage2), foomatic-rip, and Ghostscript.
52 * The "lsb" package depends on all of the above packages, and exists
53 for backwards compatibility purposes with LSB 1.3.
55 * The "lsb-base" package includes a number of functions used by init.d
56 scripts in some LSB packages; this package was separated in Debian's
57 lsb 2.0-6 package so other packages could make use of the init
58 functionality without requiring a full LSB installation.
60 For documentation of those functions (and those added for Debian's use),
61 please see the README.Debian file in that package.
63 * The "lsb-release" package includes the lsb_release command, which provides
64 information about the installed LSB modules and the underlying distribution.
66 The LSB module packages are architecture-specific because of
67 differences in the requirements of the LSB on various binary
68 architectures. In particular, each package provides
69 lsb-{module}-noarch and lsb-{module}-{arch} virtual packages.
73 This package attempts to implement the core LSB specification. Much
74 of the implementation is drawn on a talk by Wichert Akkerman
75 (http://www.liacs.nl/~wichert/talks/LSBDistro/html/) and Matt
76 Taggart's discussion of LSB 1.0 and Debian. Matt has also produced a
77 slideshow on LSB in Debian, which can be found at:
78 http://people.debian.org/~taggart/debconf2/
80 This package implements the LSB specification by:
82 - depending upon packages that implement OS services required by the
83 LSB, including libraries and programs.
85 - including the correct symlink to the dynamic linker.
87 - providing the LSB init script functionality. Some of the LSB init
88 functionality cannot be implemented without cooperation from other
89 packages or changes in policy for sarge+1; however, the remainder is
92 The intent of this package is to provide a best current practice way
93 of installing LSB packages on Debian using the Intel and PowerPC
94 32-bit architectures with the Linux kernel ("ia32" and "ppc32"). Its
95 presence does not imply that I or the Debian project believe that
96 Debian fully complies with the Linux Standard Base, and should not be
97 construed as a statement that Debian is LSB-compliant.
99 The specification is available at http://www.linuxbase.org/spec/
103 The package and its dependencies implement all of LSB on Debian, with
106 - LSB 3.2 assumes a 2.4 or later kernel. Debian ships a 2.4 kernel by
107 default on most architectures as of sarge, although 2.2 and 2.6 are
108 optional. There is no way in the Debian system to ensure a package
109 is only installed on a specific kernel release. Running LSB
110 applications on 2.2 kernels may result in subtle bugs or failures,
111 particularly if they depend on large file support or new syscall
112 interfaces introduced in Linux 2.3+.
114 (We do not consider this a bug in the package.)
116 - LSB 3.2 doesn't fully specify what the init_functions should do. I
117 have chosen to implement them in a way that is consistent with
118 Debian current practice, using the start-stop-daemon utility and the
119 echo command. For sarge+1, I expect a nicer init logging facility
122 - LSB specifies no way for a binary to request that a pid file be
123 created for it, and the spec is ambiguous about whether start_daemon
124 should create the pid file, therefore I assume the binary will
125 produce its own /var/run/basename.pid file.
127 - Debian only implements certain features of adduser if shadow
128 passwords are enabled. The lsb package will prompt the user to
129 enable shadow passwords if they appear to be disabled; however, it
130 does not force this choice on the administrator. Administrators who
131 disable shadow passwords may find that some LSB applications fail to
132 operate correctly as a result.
134 (We do not consider this a bug in the package.)
136 - The LSB specifies that several X libraries must be available on the
137 system, but does not specify the presence of either an X server or
138 any X clients. However, many LSB packages may expect these things
139 to be present, despite their absence from the spec.
141 Similarly, the printing specification requires the CUPS libraries
142 but no CUPS binaries; hence, printing may be impossible unless you
143 actually install the cupsys package.
145 (This may be a deficiency in the spec. However, we comply as-written.)
147 - The LSB specifies that cron scripts can be placed in cron.daily and
148 other directories; however, Debian's run-parts appears to ignore
149 these scripts if they contain a dot in their names. (See #118646)
150 You can work around this problem by editing /etc/crontab and
151 specifying the --lsbsysinit option; it is hoped that eventually
152 Debian will include this option by default.
154 (This is a known deficiency in debianutils, and is required for
155 backwards compatibility with expected behavior on earlier systems.)
157 - /etc/profile.d scripts aren't executed on shell startup by default
158 on Debian systems (see Debian Policy section 9.9 for an explanation).
159 LSB 3.2 is ambiguous on this requirement; /bin/sh is *not* required
160 to execute these scripts, according to its description, but the
161 lsbinstall documentation says that it is.
163 Debian policy forbids the use of /etc/profile.d by Debian packages,
164 so it is unlikely this will change (as it might be seen as
165 encouragement for Debian developers to do use it.)
167 There may be other deviations from the spec; they are bugs in this
168 package and should be reported as such using Debian's bug tracking
169 system: see reportbug(1) or your favorite bug reporting tool. (The
170 aforementioned deviations are generally bugs in the package that
171 cannot be easily fixed, or are bugs in the specification itself that
172 we hope to resolve in the near future.)
174 For more discussion of these deviations, see:
176 http://lists.debian.org/lsb-spec/2001/lsb-spec-200107/msg00002.html
177 (a discussion of deficiencies in LSB 1.0, mostly resolved)
181 - I implemented the LSB init dependencies based on Debian policy's
182 update-rc.d support. A registry of package-provided facilities and
183 their start and stop priorities is retained in
184 /var/lib/lsb/facilities. Priorities are assigned to the system
185 facilities as found on my sid systems as of today; perhaps system
186 facilities should be registered by the appropriate packages, and not
187 managed by the lsb package, but that is a sarge+1 policy decision.
189 - As of 1.3-1, a second registry of init script dependencies is
190 retained in /var/lib/lsb/depends. This is used to ensure that an
191 LSB package will not be removed if it provides an LSB facility that is
192 used by another LSB package. (If you rely on this functionality and
193 are upgrading from the 1.2 series, you will need to manually reinstall
194 all of your LSB packages.)
196 - As of 3.0-2, a third registry of files installed by lsbinstall is
197 retained in /var/lib/lsb/lsbinstall. Unlike the other two registries,
198 it is not designed to be human-readable.
200 - The facility handling scripts are written in Python. I am not
201 particularly attached to them being written in Python, but at the
202 same time I do not forsee rewriting them in $language_of_choice.
206 I have been unable to locate any LSB package that tests the init
207 script functionality of the spec. I am therefore unable to say
208 whether this package actually works as advertised. I would appreciate
209 any reports of its success or failure.
211 An example init script that tests some of these features is provided
212 as /usr/share/doc/lsb/examples/init-skeleton.
214 -- Chris Lawrence <lawrencc@debian.org>, Sun, 2 Mar 2008 02:20:47 -0600