From The Linux Foundation
Contents |
Introduction
The LSB SDK consists of a number of different components, which we need to reimplement. This document describes the work we would like to have done by the ISPRAS team.
The LSB Sample Implementation
The LSB Sample Implementation is a test environment for LSB confirming applications. For the LSB 3.x series, it is built using Linux From Scratch, but keeping this going as our own distribution going has been problematic, as it has forked from LFS, and how to use it has not been well understood.
As a result, we are working with António Meireles to provide chroot environment that will provide the LSB 4.0 environment. This will be built using the rmake/conary tools from rPath. He will be working to provide these tools for all of our architectures.
Packaging the Chroot
What needs to be done is to take this chroot environment, and package in a way which makes it easy for end-users at software companies (also known as ISV's) to use. Not all developers at ISV's have root access, even to their own workstations. This means that they sometimes have to make a request to their I/T department to install a package, or they may have to resort to using VMware Player or KVM/QEMU image.
So what is required is that the chroot image needs to be packaged into a form which can be used by the following distributions: Debian, Ubuntu, Fedora, Red Hat, Open Suse, SLES. It is desirable if the same package can be used for multiple distributions. In the ideal case there would be one RPM for the RPM-based distributions, and one dpkg for the Debian based packages. Because of differences in the desktop and networking tools between Red Hat and SuSe systems, this may not be completely possible, however.
Launching the Chroot environment from the Desktop
It should be possible to launch the chroot environment by having the desktop user select an application from the GNOME or KDE menus, and/or by clicking on an icon on the desktop. This should launch a terminal window (i.e., gnome-terminal or konsole) with a shell running in the chroot environment. When launching the chroot environment, it will be necessary to do a number of setup steps first, including:
- Setting up a bind mount so that /tmp/.X11-unix is available
- Copying an /etc/resolv.conf file into the chroot environment.
- Starting any local daemons if necessary (for example, if and when we add dbus to the LSB, it may be necessary to start a local dbus daemon before starting the chroot environment.
- Creating one or more bind mount to the ISV's application build, source, and test trees if so configured by the ISV.
When the user starts a second chroot window, it will not be necessary to redo the setup steps.
Launching the chroot environment from the Network
For some test environments, it may be necessary to launch the chroot environment via ssh. That is, it should be possible to connect to the machine using ssh using an alternate ssh box, which would cause the environment's setup script to be run if necessary (see the previous subsection), and then run the ssh command in the chroot environment.
It should also be possible for the administrator to configure an alternate IP address, in which case the LSB SI package should set up the alternate IP address via an init.d script, and start an ssh daemon listening on the standard ssh port, but on the alias interface for the alternate IP address. (i.e., configure eth0:1 to be an alias interface for the alternate IP address, and then have the alternate ssh daemon bind to the that alternate IP address.)
Running the chroot environment from a Virtual Machine
This should be accomplished by packaging an Open Suse or Fedora desktop environment with the chroot packaging described in this section. Although this will result in a larger VM Player/Qemu/KVM image than if we just packaged the chroot environment in the VM image, there are number of reasons why we should include the desktop environment.
- This may be the first exposure by an ISV to the Virtual Machine, and just the bare-bones LSB environemnt will probably be too austere and not leave a good impression.
- There are certain libraries and programs that are needed to boot a Linux system, but which are not officially part of the LSB environment. Leaving them out minimizes our developmet effort, while keeping the LSB environment "pure".
- We will probably also want to include the build environment in the same VM Player image (see next section).
Future Work
In the future, we may add to the SI environemnt various tests into the libraries to make sure that applications don't use certain flags in library API's that aren't allowed by the LSB (again because use of a particular flag might represent a portability problem). Also, if and when we add udev and hal support into the LSB, how udev and hal support will work in an SI chroot environment will require some careful design and engineering. (Note: it's unlikely hal/udev/dbus support will be in LSB 4.0 at this point.)
The LSB Build Environment
The LSB build environment should be formed by layering a number of components on top of the base chroot environment to form another chroot environment for building LSB applications. We will call this the "Build chroot environment". It will consist of
- The base chroot environment
- The C compiler, linker, and other basic programs needed to build applications as supplied by the custom rPath toolchain used to build the LSB base chroot environment
- The lsb_cc wrapper script, filtered header files and libraries (see discussion below)
This separate build chroot environment should be packaged as a separate package from the SI chroot environment, for the a similar set of distributions (Debian, Ubuntu, RHEL, Fedora, Open SuSe, SLES), and with a similar way of launching the build chroot (i.e., via a desktop menu/icon and via a network). As it turns out, some ISV's launch their builds from remote build servers, so being able to connect to the chroot environment via ssh, so being able to launch the build environment from ssh will be especially important.
lsb_cc
The lsb_cc is a currently part of the a set of tools that allow a programmer to build an LSB compliant application. It is a wrapper script around gcc which includes special header files and filter libraries that are designed to avoid or reject attempts to use interfaces that are not in the LSB. This is especially important for glibc, which supports multiple symbol versions, but which normally causes applications to link against glibc to use the most recent symbol version. The filter libraries may cause the program to use an older symbol version of an interface to assure that the resulting library is LSB compliant. The header files may also remove certain flags or constants which are not defined as part of the LSB, and for which the use may cause the application to become non-portable.
Lsb_cc exists today, but it needs to be enhanced to add some additional value. First of all, in the build environment, it should wrap gcc such that original gcc is renamed to gcc.real, and that gcc and cc should be symbolic links to the lsb_cc script. By default, the lsb_cc script should use the standard set of header files and filter libraries. However, it should be possible by adjusting a configuration file to cause lsb_cc to use a more relaxed set of heaer files and filter libraries. In the more relaxed mode, the symbol version restrictions to assure glibc downward compatibility are preserved, but other restrictions are lifted, and some additional (non-LSB) libraries are provided and allowed for use by the lsb_cc.
This relaxed mode is used for ISV's who wish to use the LSB build environment not necessarily to build LSB compliant applications, but applications which are much more likely to work on multiple distributions. The relaxed mode does not provide as much guarantees as the LSB, of course, but it makes it possible for ISV's to build binaries that while not LSB compliant, but which are more portable that those built using the latest SLES or RHEL distribution.
Future Work: Static and Dynamic Libraries
There will always be some libraries which ISV's need to use in their applications that are not available in the LSB platform; perhaps they aren't quite ready for stablization yet by their upstream maintainers. To address this need, the LSB Build enviornment needs to be able to allow ISV's to easily link these libraries in dynamically, and then have these libraries be included in the application's installation package. This will probably be related to the lsb_cc relaxed mode described above, with some extensions to make easy for the ISV to identify which additional files need to be included with the application package.
From a technical perspective, this is not terribly difficult, although there are some tricky bits related to setting the search path for dynamic objects, related to being able to easily debug the application before it has been installed, and what happens if the application is already using a customized run-time library search path.
There are a number of non-technical issues that need to be addressed, starting with licensing (this approach works with LGPL'ed libraries, but not necessarily with GPL'ed libraries, althouhg some lawyers differ on this point), and with how security updates are obtained by the application vendor and passed on to the end-user.