[lsb-discuss] Using lsb_release for other purposes

[Robert Schweikert]

I think we should not over load the information the lsb_release command
returns. If we need more info lets have a separate command.

As far as packaging is concerned we are working on the packaging API
which will hopefully give us programmatic access to information about
installed packages, and with respect to hardware we need to get going on
putting some proc info into the LSB.

Robert

Wichmann, Mats D wrote:
> 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).
>
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss
>   


-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
(robert.schweikert at mathworks.com)                        LINUX
The MathWorks Inc.
Phone: 508-647-2042