From The Linux Foundation

Using the LSB Written Specification

What it is, and what it is not

The LSB specification comprises a set of documents specifying a binary compatibility environment. The documents are structured along hardware architectures, with common material supported on all architectures in a single document known as the Generic LSB specification and then one additional supplementary document for each supported architecture. Since LSB 2.0, the LSB specification is modularized into a series of options to enable support for smaller footprint devices, and to allow devices not supporting all the options if they are not needed in a specific marketplace.

Rather than duplicate the descriptions of interfaces that are standardized by other groups such as the IEEE POSIX standards and The Open Group Single UNIX Specification, the LSB references a number of published standards and specifications. Other examples of referenced documents include, the OpenGL^TM Application Binary Interface for Linux document for the OpenGL, the appropriate ELF specifications, and the System V Interface Definition (SVID).

For each of the interfaces in these libraries there is a specification of the interface behavior, the ABI it presents, and where applicable, the symbol version. To reduce duplication and the possibility of editing errors, a reference is made to a description in one of the base standards, or possibly a reference plus a small difference (for example, "for the LSB, the -g option is also allowed"). The LSB provides a full description only when a reference specification is not found.

In addition to the Application Binary Interface (ABI), the LSB specifies some environment characteristics for Perl and Python interpreters, including interpreter location in the file system and set of modules that should be available for applications.

The LSB also defines a standard packaging format to allow portable installation of applications. The packaging format specified is a subset of RPM v3. Although packages of this format must be able to install on a compliant runtime (distribution), this does not mandate that the implementation needs to use the rpm program or database. Debian based distributions, which use the .deb format, can use programs such as alien to convert and install LSB compliant software. Some features such as trigger scripts were not included; currently these can not be supported or converted easily to other packaging formats.

A number of utilities are included in the specification. For many of these the behavior has already been defined by a POSIX specification. The Generic LSB Specification documents cases where the behavior of the command on Linux diverges from this specification or it is a Linux specific command. The criteria for selecting the commands to be included in the specification is based on those that were needed by scripts for an application to be installed, configured, and perform basic maintenance.

The LSB also mandates a hierarchy of the layout of the file tree, by referencing the Filesystem Hierarchy Standard. In the area of system initialization, the LSB introduces some new concepts for init scripts. Historically, it has been difficult to automatically determine at what stage of the boot sequence a service should be started. LSB compliant init scripts specify what services they provide and what they depend on. Thus, the system initialization service of the runtime is able to determine at what point to start or stop a service.

It is important to note, that it is not required that the LSB specification be only implementable on Linux-based systems. The intent is to allow for other operating systems to be able to present an LSB compliant Runtime Environment to applications.

Product Standard Descriptions

A Product Standard is a concise statement for certification of those parts of the LSB specification that must be implemented in a product that carries the LSB brand.

LSB Runtime Environment: The LSB Runtime Environment for IA32 (or other architectures) product standard is for platforms providing services that conform to the LSB specifications, specifically the Linux Standard Base Generic Specification common specification, in conjunction with the Linux Standard Base Specification for the IA32 (or other architectures) Architecture processor specific specification. For more details, see the Section called LSB Runtime Specific Details in the chapter called LSB Certifying for Linux Distributions.
LSB Application: The LSB Application for IA32 (or other architectures) product standard is for applications conforming to the LSB specifications, specifically the Linux Standard Base Generic Specification common specification, in conjunction with the Linux Standard Base Specification for the IA32 (or other architectures) Architecture processor specific specification. LSB applications are the consumers of services provided by the LSB Runtime Environments. For more details, see the Section called Achieving LSB Application Certification in the chapter called LSB Certifying for Software Products.

Specification Module Descriptions

A Specification Module is a unique collection of one or more functions that has value for a certain group of runtime implementations. To borrow a business term, a specification module is specific to a "vertical market". Specification modules can range from informal concepts to certified standards.

Product standards contain one or more of the following specification modules.

LSB-Core: The LSB-Core is a set of interfaces for developers targeting any general purpose Linux runtime. This includes only the basics for runtime environments.
LSB-Desktop: The LSB-Desktop provides graphics interfaces such as The X Windows System libraries or the OpenGL library and libraries built on top of them, such as Qt or Gtk. It is to be used in conjunction with the LSB-Core module.
LSB-C++: The LSB-C++ provides interfaces of the standard C++ library.
LSB-Languages: The LSB-Languages defines location of interpreters in the filesystem provides appropriate interpreted language modules
LSB-Printing: The LSB-Printing provides printing interfaces.
LSB-TrialUse: The LSB-TrialUse module combines interfaces that are allowed to be missing in the runtime environments. However, if a trial interface is provided by the runtime environment, it should behave as defined in the specification.

Functional Area Descriptions

A Functional Area corresponds to the smallest standards unit with reasonable justification for individual existence. To divide it into smaller units would not make sense since implementors that interface would implement all the smaller units anyway. Often the justification for a function will be the possibility that it will be useful for implementors who are targeting only some portions of the available standards in an a la carte manner.

Every specification module consists of one or more submodules concerning different functional areas. Some submodules are marked as 'optional'. This means that the runtime environment is allowed to miss libraries, interfaces and other entities specified in this submodule. However, if the submodule is provided by the runtime environment, it should provide all entities listed in the specification and behave as defined in the specification.

LSB Core Submodules Description

ELF: The LSB Executable and Linking Format (ELF) is the definition of the object files produced by the C compilation system.
Execution Environment: The LSB Execution Environment consists of the File System Hierarchy (referencing the Filesystem Hierarchy Standard, FHS, with some differences), minimal granted directory and file permissions, recommendations for applications on ownership and permissions, regular expression localization, filename globbing localization, and miscellaneous API behaviors.
Base Libraries: The LSB Base Libraries consists of libc, libm, libpthread, libgcc_s, libdl, libcrypt, libpam and librt.
Utility Libraries: The LSB Utility Libraries consists of libz, libncurses, and libutil.
Commands and Utilities: The LSB Commands and Utilities defines commands and utilities that should be provided by any LSB conforming implementation.
System Initialization: The LSB System Initialization consists of cron jobs, init script actions, installation, and removal of init.d files.
Users & Groups: The LSB Users & Groups specifies common names and ID ranges of users and groups
Packaging: The LSB Packaging consists of the RPM file format, script restrictions, package naming, package dependencies, and package architecture considerations.

LSB C++ Submodules Description

LSB C++: The LSB C++ defines interfaces of the libstdc++ library.

LSB Desktop Submodules Description

Graphics: The LSB Graphics defines core X11 and OpenGL libraries.

	Note
	In the LSB Written Specification, X11 libraries are additionally grouped to the Graphic Libraries subsection, and OpenGL libraries are grouped to the OpenGL Libraries subsection.

Graphics-Ext: The LSB Graphics-Ext defines additional graphics libraries, such as libfontconfig, libfreetype, etc.

	Note
	In the LSB Written Specification, every library from the Graphics-Ext module has its own subsection.

Toolkit-Gtk: The LSB Toolkit-Gtk consists of GTK+ Stack libraries.
Toolkit-Qt: The LSB Toolkit-Qt consists of Qt4 libraries.
Toolkit-Qt3: The LSB Toolkit-Qt3 defines interfaces of the libqt-mt (Qt3) library.
XML: The LSB XML consists of XML processing libraries.

LSB Languages Submodules Description

Python: The LSB Python defines environment of the the Python language interpreter.
Perl: The LSB Perl defines environment of the the Perl language interpreter.

LSB Printing Submodules Description

Printing: The LSB Printing consists of printing libraries (such as libcups).

LSB Trial Use Submodules Description

Multimedia: The LSB Multimedia defines interfaces of the libasound library (a user-space library of the Advanced Linux Sound Architecture, ALSA).
Security: The LSB Security consists of the NSS libraries.
Java: The LSB Java defines some aspects of the Java runtime environment.
Xdg-Utils: The LSB Xdg-Utils defines a set of commands that allows applications to easily integrate with the desktop environment.

Expanding the Written Specification

Below are some of the acceptance criteria for publishing or revising a LSB Specification.

The candidate must represent the "best practice" in the development community for the problem it solves. It needs to have emerged as a clear de facto standard and be available on most (or all) of the major distributions.

The upstream maintainers must be committed to backwards compatibility (for some defined version) and stability. They should be willing to work with developers and distributors on providing a standard everyone can agree on and adopt.

The upstream maintainers, distributions, and developers should be synced up on compatible versions. If not, they should be willing to agree on and adopt compatible versions.

If the distributions maintain any patches against the component, these could be merged upstream or dropped. Since the LSB is a behavioral standard, this is not required but could make things easier.

Explicitly check the upstream support; a checklist item for supporting a new architecture should be an explicit check of the upstream components to ensure the correct symbol version are specified.

A validation step must be completed prior to a spec being approved by the LSB workgroup. This validation step consists of the completion of all of the component of the LSB, Spec, tests, build environment, Sample Implementation, and application battery. Our process is not a closed loop process without all of these components being in place.

Multiple implementations should exist, and have been used in the validation step. If only a single implementation exists, then the LSB is not really needed, as no compatibility problem can exist. The LSB brand is intended for use by multiple vendors and distributions, and not as a marketing tool for a single vendor or distribution.

Downloading the Written Specification

To obtain the LSB Written Specification go to the LSB download Web page. On this page you can obtain the specifications in Adobe Portable Document Format (.pdf) or as a set of pages in the HTML Format (.html). For more formats, please refer to the LSB Specifications Archive page and follow the all formats url of the desired specification version. Additional formats include one-page HTML, RichText Format (.rtf), text (.txt), and line numbered text (_lines.txt).

Table 1. LSB Specification Modules

Document	Version	Architectures
LSB Core	4.0	Generic, IA32, IA64, PPC32, PPC64, S390, S390X, AMD64
LSB C++	4.0	Generic, IA32, IA64, PPC32, PPC64, S390, S390X, AMD64
LSB Desktop	4.0	Generic, IA32, IA64, PPC32, PPC64, S390, S390X, AMD64
LSB Interpreter Languages	4.0	Generic
LSB Printing	4.0	Generic
LSB Trial Use (ALSA, Java and xdg-utils)	4.0	Generic

[Article] [Discussion] [View source] [History]