22
The LSB implementation in Debian is currently divided into five
22
The LSB implementation in Debian is currently divided into eight
25
25
* The "lsb-core" package depends on the Debian packages that are
26
required to comply with the LSB-Core 2.0 specification; this is
26
required to comply with the LSB-Core 3.2 specification; this is
27
27
roughly equivalent to the LSB 1.3 specification, except X11 libraries
28
28
are not required. It also includes some subroutines that are used
29
29
by LSB-compliant applications when they are being installed or
32
32
* The "lsb-graphics" package depends on the X11 libraries required for
33
the LSB-Graphics 2.0 specification.
33
the LSB-Graphics 3.2 specification.
35
35
* The "lsb-cxx" package depends on libstdc++5, required for the
36
LSB-CXX (LSB-C++) 2.0 specification.
38
* The "lsb" package depends on the above three packages, and exists
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
39
53
for backwards compatibility purposes with LSB 1.3.
41
55
* The "lsb-base" package includes a number of functions used by init.d
43
57
lsb 2.0-6 package so other packages could make use of the init
44
58
functionality without requiring a full LSB installation.
46
The first three packages are architecture-specific because of
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
47
67
differences in the requirements of the LSB on various binary
48
68
architectures. In particular, each package provides
49
69
lsb-{module}-noarch and lsb-{module}-{arch} virtual packages.
53
73
This package attempts to implement the core LSB specification. Much
54
74
of the implementation is drawn on a talk by Wichert Akkerman
55
75
(http://www.liacs.nl/~wichert/talks/LSBDistro/html/) and Matt
56
Taggart's discussion of LSB 1.0 and Debian. Matt's discussion is
57
provided in the /usr/share/doc/lsb/html directory. Matt has also
58
produced a slideshow on LSB in Debian, which can be found at:
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:
59
78
http://people.debian.org/~taggart/debconf2/
61
80
This package implements the LSB specification by:
80
99
The specification is available at http://www.linuxbase.org/spec/
82
DEVIATIONS FROM LSB 2.0
84
103
The package and its dependencies implement all of LSB on Debian, with
87
- LSB 2.0 assumes a 2.4 kernel. Debian ships a 2.4 kernel by default
88
on most architectures as of sarge, although 2.2 and 2.6 are
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
89
108
optional. There is no way in the Debian system to ensure a package
90
109
is only installed on a specific kernel release. Running LSB
91
110
applications on 2.2 kernels may result in subtle bugs or failures,
95
114
(We do not consider this a bug in the package.)
97
- LSB 2.0 doesn't fully specify what the init_functions should do. I
116
- LSB 3.2 doesn't fully specify what the init_functions should do. I
98
117
have chosen to implement them in a way that is consistent with
99
118
Debian current practice, using the start-stop-daemon utility and the
100
119
echo command. For sarge+1, I expect a nicer init logging facility
118
137
system, but does not specify the presence of either an X server or
119
138
any X clients. However, many LSB packages may expect these things
120
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.
122
145
(This may be a deficiency in the spec. However, we comply as-written.)
124
147
- The LSB specifies that cron scripts can be placed in cron.daily and
131
154
(This is a known deficiency in debianutils, and is required for
132
155
backwards compatibility with expected behavior on earlier systems.)
134
- The results of running the LSB test suite against Debian with the
135
LSB package and its dependencies installed are available at
136
http://people.debian.org/~joeyh/lsbtest/current/, courtesy of Joey Hess.
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.)
138
167
There may be other deviations from the spec; they are bugs in this
139
168
package and should be reported as such using Debian's bug tracking
164
193
are upgrading from the 1.2 series, you will need to manually reinstall
165
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.
167
200
- The facility handling scripts are written in Python. I am not
168
201
particularly attached to them being written in Python, but at the
169
202
same time I do not forsee rewriting them in $language_of_choice.
171
BACKPORTING TO DEBIAN 3.0 (WOODY)
173
The scripts install_initd and remove_initd are written in Python and
174
require Python 2.2 or later to operate correctly. Woody (Debian 3.0)
175
included the python2.2 package, but the default version of Python in
176
woody was Python 2.1. To backport to woody:
178
- Change the python dependency to depend on python2.2 rather than python
179
- Change the #! lines of install_initd and remove_initd to point to
182
For proper LSB conformance in woody, you will also need to backport
183
other Debian packages, including alien.
185
The default version of Python in Debian 3.1 (sarge) is Python 2.3.5.
187
204
COMPLIANCE TESTING
189
206
I have been unable to locate any LSB package that tests the init
194
211
An example init script that tests some of these features is provided
195
212
as /usr/share/doc/lsb/examples/init-skeleton.
197
-- Chris Lawrence <lawrencc@debian.org>, Fri Mar 4 17:41:50 2005
214
-- Chris Lawrence <lawrencc@debian.org>, Sun, 2 Mar 2008 02:20:47 -0600
added
removed
debian/README.Debian
