[lsb-discuss] Using lsb_release for other purposes

Wichmann, Mats D mats.d.wichmann at intel.com
Mon Apr 7 08:11:30 PDT 2008


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

Could lsb_release be used for more than indicating
LSB dependencies?  For those who aren't that familiar,
lsb_release is a long-standing tool which allows shell
queries about the LSB conformance of a system, as well
as information about the underlying distro (should it
choose to provide it).  The LSB information is
standardized, the distro information less so.

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
Distributor ID: Fedora
Description:  Fedora release 8.92 (Rawhide)
Release: 8.92
Codename: Rawhide


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.


Now to the question - I guess there's an interest in
reporting on the presence of functionality sets roughly
equivalent to LSB modules on top of the LSB platform.
If these functionality sets are expressed through the
package manager that's fine at install time, but otherwise
we have no defined mechanism for querying - the LSB
does not require any way to query the package manager
at runtime for what it has installed.


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.

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




More information about the lsb-discuss mailing list