LSB compliance for LFS

[DJ Lucas]

This ticket serves as a staging area for LSB compliance strictly WRT LFS, as most of the unmet LSB compliance issues will fall into BLFS territory. Please append any LSB issues that fall into LFS book territory to this ticket.

For LFS, the only bit I have to add ATM are the boot scripts. Distribution provided boot scripts are not strictly required to use the LSB provided functions for LSB compliance. In fact, the lsb-v3 scripts that I've been working on do not (or rather, not directly). They use helper functions provided by the distro functions file (/etc/init.d/lfs-functions) that provide easy to use, convenience wrappers around the LSB functions. However, I would still prefer that the scripts in contrib/lsb-v3 be considered for LFS mainstream. At this time, they require only minor cleanups, and for the BLFS side, I have about ~70% of them written and in use already, though I've never added a contrib directory for them in BLFS due to naming conventions and size concerns.

I also know that Dan Nicholson is working on an implementation of install_initd and remove_initd programs written in C, but I unfortunately do not know the current status of that endeavor. However, once a stable release is created, these should also be considered for inclusion into LFS rather than BLFS, and perhaps the bootscripts makefile could also be retooled to use the new tools as soon as they are installed.

I will also be opening a few related future bugs in BLFS Trac concerning some other items that I am aware of including the bootscript naming collisions I mentioned above (NTP/setclock/$time, apache/httpd, etc.).

[dnicholson@…]

What a coincidence. I'm closing in on making a first release of the tools and was about to ping you about it. I just want to actually give them some real testing instead of just if "make check" says it's OK. If you'd like to give them a whirl, I can make a snapshot available. Progress here:

​http://gitweb.dwcab.com/?p=initd-tools.git;a=summary

(Please don't make fun of my crappy C skills)

[DJ Lucas]

Excellent! I was looking for the link when I got your response. I grabbed the latest snap from git-web. Unfortunately, I probably won't be able to begin testing until after the weekend now, but I will begin as soon as I can. Should I modify the local headers to do K only in 0 and 6, or did you work some voodoo there?

[dnicholson@…]

My intention is to drop the hack in our rc script that runs the 0 and 6 S scripts with stop. So, no, I have no voodoo to handle that. With proper dependencies in the scripts, their should be no need to do it.

However, I do plan to hack the halt and reboot scripts so they _start_ in 0 and 6. If they are the only start scripts in that level, then that should ensure that they are run last.

Also, I know you were planning to do this anyway, but please backup your rc*.d directories if you're going to test. You may also want to run with --verbose since I wrote them to be extremely quiet.

[DJ Lucas]

Backup? Of course! It'll be on a bare-bones test system at first anyway.

As far as a 'hack' to run reboot and halt as an S* script, I don't think that is necessary. As previously stated, distribution supplied scripts are not required to follow the spec. In theory, and in good practice, you should *never* encounter a vendor supplied script that requests an S link in 0 and 6. If you were to provide a config file with ignored scripts, or better to honor the X-$DISTRO-Default-{Start,Stop} headers, it wouldn't be viewed as a 'hack' at all.

I realize that I'm getting way ahead of myself here, and complicating your project quite a bit. And in fact, with the correct dependencies, it is not necessary at all short of providing the old, expected behavior. If you were to accept a list of ignored scripts, then the issue simply disappears as we could set those up in the makefile and never have to worry about them again.

[alexander@…]

I think that attempting to "conform" to LSB is a very bad idea if BLFS comes without the official binary version of the LSB testsuite. And even then, any purely testsuite-driven development is always a bad idea (the sample LSB implementation passes only LSB tests, but, due to patches that are needed to pass the tests, e.g., no longer detects certain invalid arguments to some commands).

OTOH, if we add facilities that help installation of LSB packages without using the words "conform" or "comply" in relation to (B)LFS and LSB, I welcome this move. Obviously, this requires making installation of the non-wide-character ncurses shared libraries mandatory in Chapter 6 (right now, they are optional, but that's the only ncurses libraries required in LSB--i.e., LSB-complying full-screen terminal applications simply cannot work in UTF-8 locales without linking to wide-character ncurses libraries statically).

[alexander@…]

Also, on x86-64, I am not sure whether the lib64->lib symlink is good enough for LSB (actually, FHS) or if a full multilib implementation is required.

[gerard@…]

Set milestone to 7.0. Let's see what it's going to require to fully implement such a thing (time and number/impact of changes analysis).

[bdubbs@…]

There is really no way to make LFS into a LSB compliant system without BLFS. The approach I had envisioned was to write a section either in the Introduction or Preface that describes what being LSB compliant means and how the LFS approach affects compliance. We would then add a paragraph to each part of Chapters 6, 7, and 8 that may need (optional) instructions to ensure that compatibility.

Final testing for compliance would need to be discussed in BLFS after many more packages have been added.

[bdubbs@…]

Transferring to BLFS because the package requirements for finishing LSB compliance require BLFS package support.

Marking as fixed, although that really only applies to LFS. There is a lot of work left to complete this ticket within BLFS.

Added a section about standards compliance in LFS as a part of revision 9116.