The LSB Sample Implementation (LSB-si), is a minimal LSB-conforming runtime environment used for testing purposes. Think of it as an example Linux distro that you can build yourself. It can be run in a chroot, hosted or standalone (bootable) mode. When run in hosted mode, the LSB-si allows a second test environment to live on the same machine, reducing the need for multiple dedicated test machines.

LSB compliant applications should be tested inside the LSB-si to insure they haven't picked up any distribution-specific quirks. The LSB Certification program requires an application be tested under the LSB-si.

The LSB-si can also be used in a variety of validation scenarios where there's a desire to limit what is installed to the minimal set required by the LSB.

Why another Linux build? Aren't there enough Linux distributions already?

The LSB-si is not a general-purpose distribution, it's a limited test environment, and a proof-of-concept of building to the LSB spec.

Most Linux distributions supply lots of packages, and which of them gets installed, and later added, removed or upgraded is in the local sysadmin's control. Which is as it should be, except when your job is to build a portable application that will run everywhere - how can you be sure you haven't linked in something which is not guaranteed to be present on every system where that will be installed. You can if you take advantage of the contract that LSB conforming systems offer you as an application developer: that a core set of libraries and programs will be present, and will work in the way that is documented in the LSB.

The LSB-si is a minimal implementation of that set which can be used to test programs before releasing them to the field.

For example, some software has auto-detecting build scripts (such as GNU configure), which will enable the build to make use of many things installed on a system, whether or not those are part of the LSB. Running the resulting binary in the LSB-si will help detect cases where non-LSB features have crept in, as those features likely not be present in the LSB-si.

Note that the primary testing tool for an LSB application is lsbappchk. Lsbappchk is a static tool, however, and so cannot catch runtime issues, such as calling out to another program. The LSB-si provides a way to run the application in a conforming environment.

The LSB-si also serves as a proof-of-concept of building an LSB conforming system. The policy is to use released packages from the package maintainers, with a truly minimal set of patches. Some patches are necessary to build in the LSB-si environment (often to account for the absence of some tool that is assumed by the build). A few patches are supplied to fix bugs or add LSB conformance, but generally the preference is for such patches to be picked up by the upstream maintainers and folded into their next release.

Finally, the LSB-si is able to stay in lockstep with the evolving LSB specification. New features appear in test versions of the LSB-si are they are finalized into the specification, and the LSB-si aims to release versions matching fully approved new specifications at roughly the same time as the spec. This gives developers the opportunity to preview new features before they become a fully-supported part of their favorite distributions.

The LSB-si is not designed as a standalone Linux distribution, although it can be made bootable (see How The LSB-si is Packaged). It is mainly an example and a test environment - the LSB project does not have the resources to track and fix performance and security issues that is part of the value-add of a true distributor.

The LSB-si is built from clean upstream package sources. The build instructions are captured in a set of XML files which serve as input to a tool called nALFS; the concept is derived from the Linux From Scratch project.

The build is a multi-stage process so that the final result has been built by the LSB-si itself, and the majority of dependencies on the host machine's build environment are thus eliminated. Ideally, all the dependencies would be eliminated but in practice a few minor things may leak through. In particular, the initial stage of the lsbsi build now does not do the GCC "fixincludes" step as this pulled in some details of the host system in the "fixed" header files that were then used throughout the build process. The expectation is there may be a few issues like that which are not known.

The intermediate phase of the build can be used as an LSB development environment; in effect, this is what it does when building the final phase. The final phase does not have a compilation environment, as that is not part of the LSB specification. The intermediate phase is designed to be used as a chroot environment; using the compiler directly, and not in a chroot won't work as things will point to the wrong places. Although the intermediate is built for the same architecture as the host machine it is more like a cross-compilation environment. Producing a more usable build environment is an intended future direction; the current intermediate phase is designed specifically to be able to build the final phase, and may not be the right set of tools to build other applications. The intermediate environment is not part of the released materials.

Build instructions are available.

The LSB-si is subjected to the same routine that any conforming distribution would be:

1. lsb-runtime-test, objective is 0 failures. However, as noted elsewhere in this document, if major patches are not accepted by upstream maintainers, they will not be included in the LSB-si either. Current versions thus have a few failures (see release noted).
2. lsblibchk, are all the required libraries present
3. lsbcmdchk, are all the required commands present
4. application battery, run the FVTs for all the example applications

The LSB-si is released in several configurations for each architecture:

1. Base system, a tarball containing only what is required by the LSB specification. Can be entered via chroot. For complete conformance, requires the underlying Linux kernel to be LSB conforming.
2. Graphics system, the files from the Base distribution plus files necessary to support graphical applications as described in the LSB specification. This includes many of the X11R6 shared libraries.
3. Testable system, contains the Base distribution plus additional files and programs needed to enable the LSB-si as a testing environment. This bundle can run the LSB runtime test suite and LSB conforming applications. Can be entered via chroot. Once running, it is possible to telnet into the environment. For complete conformance, requires the underlying Linux kernel to be LSB conforming.
4. Bootable system, the files from the Base distribution plus a kernel and other support to make it possible to boot standalone. Some additional configuration will be necessary - for example, an appropriate boot configuration for the target hardware and configuration of necessary kernel modules.
5. Hosted system, the files from the Base distribution plus support to run User-Mode Linux, a kernel virtual machine that runs as a user-level application on the host system. User-Mode Linux may not be available for all LSB-supported architectures (as of early 2004 it was still available ONLY for x86, although at least three other architecture ports are contemplated). The Hosted bundle is also available as an installable, ready-to-run package.

Note that when the package is extending beyond the Base, there's a tradeoff: the system becomes more usable, but includes various non-LSB commands and files, and thus is a bit less "pure" in a testing sense.

The LSB-si is a work in progress.

The Base bundles on ia32 and Itanium essentially passed the LSB 1.2 runtime test suites, but require a number of manual steps to do so (most of these are handled by using the Test bundle). Since ia32 is the only fully supported architecture under LSB 1.2, only the ia32 LSB-si was placed in the impl/released-1.2 directory.

For 1.3, four of the five supported architectures (ia32, Itanium, s390 and ppc32) are released; s390x was not completed. For the 1.3.1 release, all have a small number of failures as the addition of Li18nux tests stressed some new areas where fixes are not yet available from upstream sources, and the patches to current upstream versions, while available from the Li18nux project, would diverge too far from the LSB-si goal of "built from clean upstream sources". These failures are documented in the release notes. Their presence should not affect application testing, as they are all in the behavior of commands such as find, fold, etc. and not in the LSB programming interfaces.

As of 1.3.1, the additional bundles have also been released for the three supported architectures. As User-Mode Linux is only available for ia32 at this time, the binary rpm package for the hosted environment is only released for ia32.

Release candidate versions of what will be the LSB 2.0 version of the LSB-si are available from the LSB download page which is located here. Versions are available for all supported architectures.

Periodic reports may be found at http://www.linuxbase.org/impl/records.html.

• A list of extra (non-LSB) commands and extra libraries is available; some attention should be paid to how much of this list can be reduced.
• Construction of a build environment add-on bundle.
• Uplift to the current supported nALFS version (requires major changes to the xml and some patches to be forward ported from the version of nALFS being used).
• The functionality of the hosted (UML) environment can be improved. Current thinking is not to expand the released package, but to use the Application Battery to build additional packages, such as dhcp client support, ssh client and server, etc. These could then be installed in the hosted environment as per need.
• More data points would be helpful on the build from source. We'd like to insure that the build is truly portable.

To help, Join the lsb-impl mailing list. Send questions to the list, or file bugs at the LSB bugtracker, put them in the "impl" category (it really helps if you log in, and it costs nothing to obtain an LSB Gforge ID).