Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package
Package: wnpp
Version: N/A; reported 2002-02-18
Severity: wishlist
* Package name : lsb
Version : 1.1.0
* URL : http://www.linuxbase.org/
* License : GPL, BSD
Description : Linux Standard Base 1.1 core support package
The Linux Standard Base (http://www.linuxbase.org/) is a standard
core system that third-party applications can depend upon.
.
This package provides an implementation of version 1.1.0 of the Linux
Standard Base for Debian on the Intel x86 architecture. Future
revisions may support the LSB on additional architectures.
.
The intent of this package is to provide a best current practice way
of installing LSB packages on Debian GNU/Linux. Its presence does
not imply that we believe that Debian fully complies with the Linux
Standard Base, and should not be construed as a statement that Debian
is LSB-compliant.
My README.Debian text follows, which pretty much explains how this
package works:
lsb for Debian
--------------
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
Taggert's discussion of LSB 1.0 and Debian
(http://people.debian.org/~taggart/lsb/).
It does so in a number of ways:
- Providing directories that appear to be missing from Debian's FHS
hierarchy. (These directories probably should appear in base-files
eventually.)
- Depending upon packages that implement OS services required by the
LSB, including libraries and programs.
- Including the ld-lsb.so.1 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 woody+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 woody on the ia32 architecture.
Its presence does not imply that I believe that Debian fully complies
with the Linux Standard Base, and should not be construed as a
statement that Debian is LSB-compliant.
DEVIATIONS FROM LSB 1.1
The package and its dependencies implement all of LSB on Debian, with
these exceptions:
- LSB 1.1 assumes a 2.4 kernel. Debian ships a 2.2 kernel by default
as of woody, although 2.4 is optional. There is no way in the
Debian system to ensure a package is only installed on a specific
kernel release.
- LSB 1.1 specifies definitions for run levels 2-5 that correspond
with most Red Hat-like distributions. Debian does not specify run
levels 3-5, and RL 2 can theoretically encompass any of LSB 2-5.
(LSB probably should implement init dependencies for facilities
expected in run levels, rather than using run levels directly.)
In practical terms, this means that some packages may not install
init scripts in RL 2-4 that would be expected on a system running an
X display manager. This package obeys the LSB spec by using the
specified run levels of LSB applications; however, my gut feeling is
that any LSB RL from 2-5 should be treated as 2-5 inclusive on
Debian until Debian conforms (unlikely for woody) or LSB is amended
to get rid of this silliness.
- LSB 1.1 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 woody+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.
There may be other deviations from the spec; they are bugs and should
be reported as such. (The aforementioned deviations are bugs, but
probably "wontfix" for woody, or are bugs in the spec.)
DESIGN DECISIONS
- I implemented the LSB init dependencies based on sysvinit's priority
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
unstable boxen as of today; perhaps system facilities should be
registered by the appropriate packages, and not managed by the lsb
package, but that is a woody+1 policy decision.
- 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.
NOTES
Per the spec, LSB applications may be installed on Debian using:
alien -i YOUR_APPLICATION_HERE.lsb
You may need to run 'apt-get -f install' afterwards to pull in this
package. Of course, you wouldn't be reading this if you hadn't
already pulled it in.
-- Chris Lawrence <lawrencc@debian.org>, Sun, 17 Feb 2002 14:07:32 -0600
The package in source and i386 binary (it's really arch-independent,
but the spec only is final on Linux/ia32) is at
http://people.debian.org/~lawrencc/
Note: I can't actually find any LSB packages that test whether the
implementation works right or not. I downloaded the lsb-apache rpm
from ftp://freestandards.org/pub/lsb/app-battery/apache/, and alien
handled it OK, and dpkg installed it without complaining of missing
dependencies, but an equivs-based lsb could have done that! (The
prerm and postinst don't do anything...)
(Alien chokes on their rsync:
Unpacking of `rsync-2.4.6-1.i386.rpm' failed at /usr/share/perl5/Alien/Package/Rpm.pm line 140.
Mozilla doesn't have an LSB rpm.)
Your questions and comments are most welcome. I'd particularly like
any comments on streamlining and generalizing the depends list, as I
suspect a few redundant dependencies are in there (alien probably
pulls in a lot of libraries based on what it pulls in, for example).
Also, if you actually have a LSB package that uses the init
facilities, I'd love to see test results.
Finally, the package probably should be built as native but numbered
(like now) as UPSTREAM-DEB.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux quango4 2.4.18-pre7-ac1 #1 Tue Jan 29 15:12:07 CST 2002 i686
Locale: LANG=C, LC_CTYPE=en_US
Reply to: