[lsb-discuss] Updated lsb_release proposal

Robert Schweikert 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.

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.

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[0][: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 
runtime burden.


Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
rjschwei at suse.com
rschweik at ca.ibm.com

More information about the lsb-discuss mailing list