On 10/16/2016 06:04 PM, Bruce Dubbs wrote:
DJ Lucas wrote:

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
 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
 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?).


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

The book says to give LSB_VERSION the value of "1.4" unconditionally. What I was getting at is that "1.4" is really old and is the old format (and actually, I just realized that it's not even a valid version of the spec). "1.3" is valid (though it's 14 years old), "2.0" is not valid, "core-2.0-noarch" is valid (12 years old), as well as "core-5.0-noarch:core-5.0-amd64:desktop-5.0-amd64:graphics-5.0-amd64:trial-gtk3-5.0-amd64".

If doing in stages, just adding an empty file is easier to explain in the book (and for distro maintainers), in that you simply create an empty file in the /etc/lsb-release.d directory to append to the core-$ver-noarch value. This is all moot until I (or somebody else) test, but at least the echo statement should be removed in the interim.


FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to