On 10/16/2016 03:12 PM, BLFS Trac via blfs-book wrote:
Reporter: dj@… | Owner: blfs-book@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.11
Component: BOOK | Version: SVN
Severity: normal | Resolution:
Comment (by bdubbs@…):
What information would go in /etc/lsb-release.d/?
What would be in a colon separated list?
The url appears to be red-hat specific, but the README says:
Note that this is an \example/ implementation.
The specification requires only an lsb_release command to exist, and to
return the information in the format described. The fact that the
page generated from this software describes implementation details
example should not be construed as placing any additional requirements
on implementors beyond those just noted. In particular, the
format of the /etc/lsb-release file and the /etc/lsb-release.d
are not part of the LSB specification
My recommendation is to mark wontfix.
You are correct, /etc/lsb-release.d is not necessary, but it's also
to add modules as you progress. Unfortunately, you beat me to the list
post that I was writing. :-) The only thing that *needs* to be done is to
remove the echo command, and update the help output in the script.
If you've installed the deps for the core-generic part of the spec (and
ran the compliance tests), you can add the following:
case $(uname -m) in
echo 'LSB_VERSION="core-5.0-noarch:core-5.0-ia32"' >>
echo 'LSB_Version="core-5.0-noarch:core-5.0-amd64"' >>
I plan to do it anyway (along with the 50 other tasks I have in mind at
some point), but not sure if BLFS should. I'm kind of thinking we should
leave the "n/a" alone and just leave it for now. Redhat provides their
implementation (the 2.0 version is actually an update to the FSG version
that we use currently). There is no tarball distributed by the LSB
group. We could just as easily create our own, use RedHat's (as we do
currently), or Debian uses a python script. At any rate, the manpage we
have currently (and instructions for LSB_VERSION) is long out of date.
version string changed to use modules. As far as providing our own, also
easy enough. I'm partial to the RedHat version, but that's just ease of
use, minimal change.
The question is what spec to follow and whether that's a needed goal for
BLFS. A 2003 spec, if even accurate--I have not actually run any
tests--probably isn't all that valuable anymore. My question as to
to continue to include this, revolves around the modular parts of the
spec. For instance, in addition to the prefix to the above case
after that, "If you've installed gtk, atk, and desktop-file-utils,
whatever else is required for graphics part of the spec..." and then the
command block is either case $(uname -m)...touch
/etc/lsb-release.d/graphics-5.0-ia64, or if sticking with the 1.4
edit the /etc/lsb-release file and append "graphics-5.0-ia64" or
"graphics-5.0-ia32". I don't think it'd be too terribly difficult to do,
but it requires a significant amount of time for very little gain. At
least, we should remove the echo that is currently in the book and leave
it at "Not Implemented". I'm not sure about "n/a" vs "Not Implemented" in
the output, the spec doesn't mention it (presumably because it doesn't
make much sense to have the command if not LSB compliant?).