[lsb-discuss] Updated lsb_release proposal
rjschwei at suse.com
Mon Apr 9 19:28:48 UTC 2012
As discussed last week at the F2F I have updated the proposal for the
lsb_release command on the Modularization design proposal page, see
I have also provided a list of incompatibilities that would be
introduced by this approach and a rational behind the decisions. For
completeness I'll list these here to make the discussion a bit easier.
-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.
The wiki page also contains some ideas about how we could deal with
these incompatibilities, if we think it is necessary. However, I have
come to the conclusion that the new output is very easy to distinguish
from the old output and thus a client can simply switch the way the
client parses the output. Here is a Python snippet that would do this:
lsbInfo = os.system('lsb_release --version').readlines()
if lsbInfo[:11] == 'LSB Version':
Yes, until RHEL 5,6 and SLES 11 die in about 10 years client code has to
carry this around. But code like this would be expected to be isolated
to an installer and thus would not present a continued maintenance or
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
rjschwei at suse.com
rschweik at ca.ibm.com
More information about the lsb-discuss