[lsb-discuss] Using lsb_release for other purposes

Ken MacLeod ken at bitsko.slc.ut.us
Sun Apr 13 10:40:43 PDT 2008

mats.d.wichmann at intel.com (Wichmann, Mats D) writes:

> Had a query on IRC that I wanted to forward here for wider
> discussion.

> (I hope I've expressed this request accurately, if not hopefully the
> original requstor will update the information here).

I'm the original requester from IRC, I'll followup with a longer bio
when I can but in short my background is 20 years Unix/Linux, mostly
in systems development and management, and most recently 3 years in
ATCA/Telecom with an OEM providing embedded and general purpose
computing blades and processor-on-card modules.  I am not officially
representing my company at this time on this topic.

> Could lsb_release be used for more than indicating LSB dependencies?

Here is the context:

In ATCA/Telecom there are up to five organizations involved in
delivering and deploying systems:

 * Linux OS distribution which is the implementation that conforms to
   LSB as required by Carrier Grade Linux.

 * Original equipment manufacturer (OEM) who is also typically an ISV
   for their platform.

 * Network equipment provider (NEP) who integrates systems and is also
   typically an ISV for their platforms.

 * 3rd party ISVs who provide additional applications.

 * Service providers (SPs), the equipment end-user who deploys systems
   that serve telecom customers, who may also have their own

The first organization, the LSB implementation, identifies its
conformance to LSB so that the latter organizations can effectively
develop LSB conforming applications.

Here is the use case:

The first four organizations need a way to identify provider or
industry specifications that the they conform to beyond LSB.  As an
OEM, our specific case is of our base platform software specification
and application platform specifications (for example, media server and
data path platforms).

I also envision use cases for conformances to Carrier Grade Linux, the
NEPs and 3rd party platforms, and making the "module" identification
more open to other specification bodies in general.

The preference for expanding lsb_release to support this
identification is that it allows the LSB conforming application to
have one interface to determine conformance to specifications.

Within this use case, we may also support two independent generations
of product releases on one generation of LSB implementation.  For
example, the customer can choose between our-1.0 and our-2.0 on RHEL4
which is core-3.0-{ia32,noarch}.

I did consider a package-based approach as Robert suggests but
initially rejected it because without further specification packages
alone don't provide a way to query or report all implemented modules.
Specifying a way for packages to extend lsb_release to provide this
information looks straightforward along the lines Mats describes
below, which is what I too had first prototyped.

> The LSB information is standardized, [...]

> For example, on one system I have:
> LSB Version:
> core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch

> Now it turns out that to allow for the concept of modules that may
> or may not be present on a system, we ended up defining in the
> sample implementation of lsb_release a directory /etc/lsb-release.d
> (this directory is not in the LSB specification, at the moment it's
> an implementation detail of our sample).  In this directory, if a
> filename appears, it's reported by the lsb_release command.  In the
> example system I alluded to above, the four fields reported by "LSB
> Version" each appear as a filename in this directory.  The files
> have no contents.  The idea here was that the dependency package
> that provides the module could drop an empty file in this directory
> and that makes it available to be reported by lsb_release.

> [...]

> Would it be a good idea to allow the extension of the lsb_release
> machanism for developers to express the presence of functionality as
> described above?  The LSB specification impact would be that we'd
> have to enshrine either /etc/lsb-release.d or an equivalent
> directory that packages can write into, and enforce some namespace
> rules on the contents of the directory; as well as extending the
> number of fields reported back by the lsb_release command itself.

Here is a more concrete proposal:

First, as Mats describes, specifying the /etc/lsb-release.d directory
as part of the interface for conforming "platform" LSB applications to
place a file that indicates that the platform in turn provides an
implementation that other LSB applications can depend on.  The
definition of "platform LSB application" used here would typically be
implemented by several installed packages with one package being the
"release" package.

For the namespace, lsb_release defines the LSB module description as a
dash-separated tuple of module name, version and architecture.  First
preference would be to follow sec. 22.5, Package Naming rules and use
names like 'example.com-1.2-noarch' and 'example.net-module-3.4-ia32'.
However, that introduces a new dash which may break existing
implementations and applications.  Second preference would be to
follow sec. 16.2.1, File Naming Conventions and use LANANA reserved
names or DNS names where a module may be prefixed (logically a
sub-domain) of the owner's name like 'example.com-1.2-noarch' and

I have prototyped this on a system whose implementation of lsb_release
uses /etc/lsb-release.d and using the second preferred namespace.  I
have packages that install the above examples into /etc/lsb-release.d
and lsb_release reports:

LSB Version:    :core-3.0-ia32:core-3.0-noarch:example.com-1.2-noarch:graphics-3.0-ia32:graphics-3.0-noarch:module.example.net-3.4-ia32

What are the next steps in circulating a proposal to appropriate


  -- Ken

More information about the lsb-discuss mailing list