DJ Lucas wrote:
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 manual
page generated from this software describes implementation details of this
example should not be construed as placing any additional requirements
on implementors beyond those just noted. In particular, the existance and
format of the /etc/lsb-release file and the /etc/lsb-release.d directory
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 easier
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"' >> /etc/lsb-release
echo 'LSB_Version="core-5.0-noarch:core-5.0-amd64"' >> /etc/lsb-release
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 working
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. The
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 whether
to continue to include this, revolves around the modular parts of the
spec. For instance, in addition to the prefix to the above case statement,
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 version,
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 very
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?).
What we have now is "LSB Version: unavailable"
If a user wants to update it, it needs to have all the files listed in the
appropriate section of
If you don't have all the packages in Core, then none of the other
sections matter. We do not have a reasonable way to test that all
packages needed are present so the /etc/lsb-release files is updated.
That needs to be done manually by the user.
I'll note that I use lsb_release in my scripts:
echo "`date` $tarball" >> /usr/src/packages-$(lsb_release -r|cut -f2).log
Unsubscribe: See the above information page