The design is based on the existing module structure in LSB 4.1 as shown in the LSB-Navigator.
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.
The figure below depicts the submodule structure considering the name changes and merges discussed previously.
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
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||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 -p LSB-Desktop:LSB-Toolkit-Qt 1
-> lsb-release -p LSB-Desktop 0
-> lsb-release -p LSB-Core 1
-> lsb-release -p LSB-Printing:LSB-Print 0
-> lsb-release -p LSB-Python 1
-> 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 ==== Goldilocks ==== mydistro 1.9 x86_64 ==== Gold LINUX ==== 1.9 ==== 0.2
-> lsb-release -d mydistro 1.9 x86_64
-> lsb-release -c Goldilocks
-> lsb-release -r 1.9
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.
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.
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.
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.