The Linux Foundation


From The Linux Foundation


LSB Modularization Design

The design is based on the existing module structure in LSB 4.1 as shown in the LSB-Navigator.

Changes to Modules and Submodules

  • Naming is changed for submodules to use "-" as word separator as well
    • Presumably the "_" word separator was used to avoid DB difficulties with duplicate names. However, this would require people to remember two word separators which is undesirable.
    • This change requires some naming changes (more on these below) to avoid DB difficulties.
  • Change the name of the LSB_Core submodule to LSB-Base
  • Eliminate the LSB-CXX module
    • Merge the content of the LSB_Cpp submodule into the LSB-Base submodule
    • LSB-CXX exists for historical reasons that were related to the LSB being an ISO standard. Due to a pending application at the time C++ was added to LSB it was not possible to modify LSB-Core. This restriction no longer exists.
    • Merging LSB-Cpp into the LSB-Languages module may also be an option. However, it appears that most systems need to have the C++ runtime libraries to run applications, therefore we might as well place C++ into the LSB-Base submodule.
  • Merge the content of LSB_Graphics_Ext into LSB-Graphics
    • It appears that the distinction between Graphics and Graphics_Ext does not provide a large enough benefit to warrant the split.
  • Move LSB_XML submodule from LSB-Desktop to become the LSB-XML submodule in LSB-Langauages
    • XML is useful not just in a desktop environment and it is classified as a language.
  • Change name of LSB_Desktop_Misc to LSB-Toolkit-Independent
  • Change name of LSB-Printing submodule to LSB-Print
    • Avoid name conflicts in the DB
  • Change word separator on all not previously mentioned submodules from "_" to "-"

Module Dependency Structure

The figure below depicts the module dependency structure of the remaining modules after the changes outlined above are applied. The LSB-TrialUse module is retained in the module hierarchy but not depicted as the dependency of the LSB-TrialUse module will depend on its submodules. At the time of this writing no trial use submodules exist in the LSB.


As more commands and libraries get added to the LSB it may be necessary to create new modules.

Submodule structure

The figure below depicts the submodule structure considering the name changes and merges discussed previously.


Exposing The LSB Modules

The LSB modules and submodules are exposed to the user through the lsb-release command. This command is already part of the standard and provided by distributions. The command provides the following options:

no argument                         Invoking the command without arguments prints information about the LSB
                                    and the installed modules and submodules in the form

                                    Module     Submodule     Version

                                    For the LSB itself no submodule information is printed, only the version
                                    number. For Modules and submodules no version number is printed as separate
                                    releases with different version numbers for modules and submodules are not
                                    supported, the LSB is released as one unit with one version number.

-a   --all                          Display all information as if the command would be called in succession with
                                    no arguments, followed by -c, followed by -d, followed by -i, followed by -r,
                                    followed by -v. Each block of information is separated by 4 = signs

-c   --codename                     Display a codename for the distribution on a single line. If there is no codename the
                                    output may be empty

-d   --description                  Display a description of the distribution on a single line. The description is in the form

                                    Name  Version  Architecture

                                    Where: Name         -> name of the distribution
                                           Version      -> release version of the distribution
                                           Architecture -> one of the LSB release architectures
                                                           ia64, ppc32, ppc64, s390, s390x, x86, x86_64

-h   --help                         Print this message

-i   --id                           Display a vendor identification string on a single line

-m                                  Same output as invocation of command with no argument but using a "|" (pipe)
                                    as field separator. This allows users to easily parse the output.

-p   --provides Module|Submodule    Return true (1) if the given module or submodule is installed. Only returns
                                    true for a module query if all submodules of the given module are installed.
                                    For a submodule query the module name and submodule name are separated by a : if
                                    the module name is specified.

-r   --release                      Display the release version of the distribution

-v   --version                      Version of the command implementation

Examples of lsb-release use

The -> symbol indicates the command line prompt.

-> lsb-release
LSB                              5.0
LSB-Core         LSB-Base
LSB-Core         LSB-Security
LSB-Desktop      LSB-Graphics
LSB-Desktop      LSB-Tookit-Qt
LSB-Languages    LSB-Python
-> lsb-release -m
-> lsb-release -p LSB-Desktop:LSB-Toolkit-Qt
-> lsb-release -p LSB-Desktop
-> lsb-release -p LSB-Core
-> lsb-release -p LSB-Printing:LSB-Print
-> lsb-release -p LSB-Python
-> lsb-release -a
LSB                              5.0
LSB-Core         LSB-Base
LSB-Core         LSB-Security
LSB-Desktop      LSB-Graphics
LSB-Desktop      LSB-Tookit-Qt
LSB-Languages    LSB-Python
mydistro 1.9 x86_64
-> lsb-release -d
mydistro 1.9 x86_64
-> lsb-release -c
-> lsb-release -r

lsb_release command incompatibilities

The new command has some incompatibilities with the command that is specified in previous versions of the LSB. The reasoning behind these incompatibilities is that LSB 5.0 will by definition be incompatible with previous releases of the LSB as LSB-Qt3 will be dropped for LSB 5.0. Additionally the previous interface was not well defined and vendor specific variations of lsb_release were possible without an easy detection mechanism for the end user.

Command incompatibilities

  • -s --short option
    • This option is no longer supported in the new version of the command. The definition of the output of the command using the -s option is not sufficiently succinct, thus allowing distribution specific variation. Further, the output of the command eliminates superfluous output (in the implementation tested). Superfluous output is eliminated by default, see below, thus the option is no longer needed.
  • -v --version option
    • This option previously displayed information about the LSB release of the distribution, including module information. Additionally this was synonymous with calling the the command without arguments. The old behavior presents a number of problems:
      • It provides no way to differentiate the output of the lsb_release command based on the version implementation of the command itself as the version identifier is used to return the LSB release version.
      • It exposes module names that were not prescribed by the LSB, thus allowing distribution specific values
      • Modules are not part of any version of the LSB prior to 5.0, therefore providing module information is wrong
    • Avoiding the overloading of the "no arguments" call with the "-v" call allows us to clearly demarcate the change in behavior. Additionally, providing information about the version of the command implementation with the "-v" argument will allow users to identify bugs or features that may be associated with a given release of the command. Ideally distributions would use the LSB work group reference implementation for of lsb_release, but as this is not a necessity for LSB certification, versioning of the command itself is very useful.
  • Output for call with -a, -c, -d, -i, and -r is modified
    • In previous versions of lsb_release the output was prefixed by some identifier followed by a colon (:). This prefix is generally superfluous and requires the user to add an additional parsing step if the interface is used in a script. Dropping the identifier eliminates the superfluous output and additional parsing step.

Dealing with the incompatibilities

One option to deal with the incompatibilities may be to rename the command to lsb-release, lsbrelease, or lsb-info. In the first two cases the rename is not necessarily obvious as a "_" changes to a "-" or just gets removed. Additionally distributions may already have the lsb-release command as a link to lsb_release. Another option my be to support the old output format, as much as possible if the user sets an environment variable (LSB_RELEASE_OUTPU=old). We could also add a command line argument to lsb_release that allows the user to toggle "old" vs. "new" behavior. However, it is not obvious that a clean solution to this problem exists, nor is it obvious whether a backwards compatibility solution is necessary at all. The new command can very easily be identified and thus client code can easily switch between parsing new style output vs. parsing old style output.

Handling Of Trial Use Modules

Trial use modules are treated a "regular" modules as far as the lsb-release command is concerned. Any module designated a "Trial Use" is automatically a submodule of the LSB-TrialUse module. Trial use modules are named as they would be named if the given module were included in the LSB. The intention is to avoid renaming exercises if/when a module moves from trial use to LSB inclusion. For example, if Ruby were to be included as a trial use module it would be named LSB-Ruby and queried as follows:

-> lsb-release -p LSB-TrialUse:LSB-Ruby

The module, if accepted could then move to LSB-Languages without being renamed.

Items to discuss prior to finalizing the design

It is not possible to think of everything ahead of time or to cover every corner case. However, we want to record items that were discussed during the finalization of the design to keep a record of the decision process.

  • What do we do with language bindings to toolkits such as python-gtk if these should get added?
    • If these were placed in LSB-Language or LSB-Desktop:LSB... this might create weird dependency chains
    • Would a new module LSB-Language-Bindings make sense in this case?
  • Should we treat submodules that are being deprecated as LSB-Deprecated submodules?
    • This implies that we move submodules from their original module to a new Deprecated module
      • In this case lsb-release should probably return true for a submodule query in the original location and the new location
    • But what if the we deprecate a module, i.e. LSB-Desktop?
      • This appears a very unlikely corner case and we probably do not need to worry about this at this time.

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