On 10/16/2016 03:12 PM, BLFS Trac via blfs-book wrote:
#8440: lsb-release-2.0
-------------------------+--------------------------
Reporter: dj@… | Owner: blfs-book@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.11
Component: BOOK | Version: SVN
Severity: normal | Resolution:
Keywords: |
-------------------------+--------------------------
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
i?86)
echo 'LSB_VERSION="core-5.0-noarch:core-5.0-ia32"' >> /etc/lsb-release
;;
x86_64)
echo 'LSB_Version="core-5.0-noarch:core-5.0-amd64"' >> /etc/lsb-release
;;
esac
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?).
https://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/lsbrelease.html
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
