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



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

Reply via email to