lsb for Devuan
--------------

This package provides the Linux Standard Base on Devuan 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 Devuan.  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 Devuan 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 Devuan is currently divided into eight
packages:

* The "lsb-core" package depends on the Devuan packages that are
  required to comply with the LSB-Core 4.1 specification. 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 4.1 specification.

* The "lsb-cxx" package depends on libstdc++6, required for the
  LSB-CXX (LSB-C++) 4.1 specification.

* The "lsb-desktop" package depends on the Gtk+ and Qt libraries required
  for the LSB-Desktop 4.1 specification.

* 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 (libcups2
  and libcupsimage2), foomatic-filters, and Ghostscript.

* The "lsb" package depends on all of the above packages.

* The "lsb-base" package includes a number of functions used by init.d
  scripts in some LSB packages.

  For documentation of those functions (and those added for Devuan's use),
  please see the README.Devuan 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 Devuan.  Matt has also produced a
slideshow on LSB in Devuan, 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 Devuan using the Intel and PowerPC
32-bit architectures with the Linux kernel ("ia32" and "ppc32").  Its
presence does not imply that I or the Devuan project believe that
Devuan fully complies with the Linux Standard Base, and should not be
construed as a statement that Devuan 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 Devuan, with
these exceptions:

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

- Devuan 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, Devuan'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
  Devuan 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 Devuan systems (see Devuan 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.

  Devuan policy forbids the use of /etc/profile.d by Devuan packages,
  so it is unlikely this will change (as it might be seen as
  encouragement for Devuan 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 Devuan'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 Devuan 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 <lawrencc@debian.org>, Sun,  2 Mar 2008 02:20:47 -0600

 LocalWords:  LSB