LWN.net Logo

The first three LSB-certified distributions

The first three LSB-certified distributions

Posted Aug 14, 2002 20:26 UTC (Wed) by erat (guest, #21)
Parent article: The first three LSB-certified distributions

Last time I checked, Red Hat (and, I would assume by association, Mandrake) wasn't even close to LSB compliance. None of the SysV init stuff that LSB mandates (install_initd, remove_initd, killproc utilities, etc.) was included, no "lsb" RPM package existed (LSB mandates that all applications built/packaged in an LSB manner have an "lsb" dependency), nothin'. Contrast that with SuSE which almost complies to the letter with the LSB specs.

Did I miss something?

If Red Hat posted some kind of LSB compliance package that people can download and install to be LSB compliant I'd love to hear about it. Their web site is mum about all of this except for a Free Standards Group press release (oddly enough, the press release on redhat.com states that 4 distros were certified, adding OpenLinux to the list. Um, huh?...).


(Log in to post comments)

The first three LSB-certified distributions

Posted Aug 14, 2002 22:53 UTC (Wed) by breser (guest, #3260) [Link]

Not sure about redhat but Mandrake does indeed have an lsb rpm package.

RedHat released redhat-lsb package

Posted Aug 14, 2002 22:59 UTC (Wed) by proski (subscriber, #104) [Link]

This file appeared recently (August 7) in the RedHat updates: ftp://updates.redhat.com/7.3/en/os/i386/redhat-lsb-1.2.0-1.i386.rpm

I guess you should be LSB compliant if you install this update. However, I installed it, but I still don't have any killproc in the PATH.

RedHat released redhat-lsb package

Posted Aug 14, 2002 23:05 UTC (Wed) by erat (guest, #21) [Link]

Way cool... I'll have to download it and check it out.

For the record, though, things like killproc can be either binary utilities (like in SuSE) or functions that can be sourced into SysV init scripts. The real test is whether or not they have the "install_initd" and "remove_initd" binaries (they act like "chkconfig --add" and "chkconfig --del" for LSB systems).

Thanks for the info!

RedHat released redhat-lsb package

Posted Aug 14, 2002 23:26 UTC (Wed) by proski (subscriber, #104) [Link]

Examining the redhat-lsb package shows that killproc is defined as an alias in /lib/lsb/init-functions along with some other aliases. /usr/lib/lsb/install_initd and /usr/lib/lsb/remove_initd are symlinks to /sbin/chkconfig. That's why I couldn't find them initially - I don't have /usr/lib/lsb in the PATH (and I don't think I should have).

RedHat released redhat-lsb package

Posted Aug 15, 2002 3:29 UTC (Thu) by jamesh (subscriber, #1159) [Link]

This might be of some help:

$ rpm -q --provides -p redhat-lsb-1.2.0-1.i386.rpm
lsb = 1.2.0
redhat-lsb = 1.2.0-1

$ rpm -qlv -p redhat-lsb-1.2.0-1.i386.rpm
-rw-r--r--    1 root    root               20 Aug  8 01:12 /etc/lsb-release
drwxr-xr-x    2 root    root                0 Aug  8 01:12 /etc/redhat-lsb
-rwxr-xr-x    1 root    root               70 Aug  8 01:12 /etc/redhat-lsb/lsb_killproc
-rwxr-xr-x    1 root    root              243 Aug  8 01:12 /etc/redhat-lsb/lsb_log_message
-rwxr-xr-x    1 root    root               59 Aug  8 01:12 /etc/redhat-lsb/lsb_pidofproc
-rwxr-xr-x    1 root    root              254 Aug  8 01:12 /etc/redhat-lsb/lsb_start_daemon
lrwxrwxrwx    1 root    root               13 Aug  8 01:12 /lib/ld-lsb.so.1 -> ld-linux.so.2
drwxr-xr-x    2 root    root                0 Aug  8 01:12 /lib/lsb
-rwxr-xr-x    1 root    root              413 Aug  8 01:12 /lib/lsb/init-functions
-rwxr-xr-x    1 root    root            14619 Aug  8 01:12 /usr/bin/lsb_release
drwxr-xr-x    2 root    root                0 Aug  8 01:12 /usr/lib/lsb
lrwxrwxrwx    1 root    root               23 Aug  8 01:12 /usr/lib/lsb/install_initd -> ../../../sbin/chkconfig
lrwxrwxrwx    1 root    root               23 Aug  8 01:12 /usr/lib/lsb/remove_initd -> ../../../sbin/chkconfig
-rw-r--r--    1 root    root             1580 Aug  8 01:12 /usr/share/man/man1/lsb_release.1.gz

The first three LSB-certified distributions

Posted Aug 15, 2002 14:10 UTC (Thu) by samadhi (guest, #2434) [Link]

It was my understanding that in order to acheve LSB compliance it was also necessary to comply to FSH 2.2. As far as I can see SUSE is the only one of the 3 distributions mentioned that comes close to this standard (Both of the others seems to be content on dropping everything into /usr, rather than /opt where appropriate). Not to mention the added benefit that for those not using journalled FS (Don't know if this really still applies to anyone?) /usr does not end up taking hours to recover after a hardware failure.

From my point of view I would have thought this was probably one of the most important (and easy) standards to adhere to, in order that both users and software companies know exactly where to look for, or place their installed software.

The first three LSB-certified distributions

Posted Aug 15, 2002 15:59 UTC (Thu) by erat (guest, #21) [Link]

It does seem like some of the standards have been, shall we say, "loosened" a bit as far as LSB certification is concerned. The symlinks from {install,remove}_initd to chkconfig definitely circumvent a lot of sysinit stuff in LSB 1.1. The chkconfig headers are completely different from LSB headers in init script. Perhaps chkconfig has been quietly enhanced to support the LSB headers as well? If not, Red Hat will not be able to set up the /etc/rc.d/rc#.d symlinks at all from LSB compatible init script headers No runlevel symlinks, no workie without a manual setup (the exact thing LSB is designed to prevent).

I'm definitely going to look into this. A common sysinit scheme (including utilities/functions for handling processes) removes a *tremendous* amount of complexity from the creation of "portable" RPM packages. If LSB certification circumvents the exact specifications LSB is supposed to standardize, the certification is almost entirely useless.

/usr versus /opt

Posted Aug 19, 2002 12:43 UTC (Mon) by Deno (guest, #2765) [Link]

Be so kind, and READ the specifications of FSH before repeating this SuSE-PR over-and-over again. "/opt" is meant for third-party packages (mainly commercial software), while "/usr" is meant for the distribution itself. While it may be convenient for you to have KDE in /opt, there is nothing in FSF that would require this.

/usr versus /opt

Posted Aug 19, 2002 16:15 UTC (Mon) by samadhi (guest, #2434) [Link]

I am not spouting SUSE PR as you put it, in fact the only reason I knew about this was when I swapped from SUSE to Mandrake about 2 years ago all the files had moved. When I READ the FHS I interpreted the line :
Programs to be invoked by users must be located in the directory /opt/<package>/bin
to mean exactly that. I suppose this could depend on your definition of what classes as a standard part of the distribution and what classes as optional software.

The definition I have always seen implemented on POSIX compliant UNIX systems would mean that software such as Office suites, Java, browsers etc should reside in /opt as this is optional software that is not necessary for the distribution to work.

You have missed a lot...

Posted Aug 19, 2002 12:40 UTC (Mon) by Deno (guest, #2765) [Link]

- You have missed the lsb-compliance packages issued by both RH and Mandrake.
- You have also missed about 3 years of development of MandrakeLinux as a completely separate distribution from RH.

Don't know what else you may have missed, but it wouldn't surprise me to see elephants and Empire State Building on the list.. ;-)

Try to think for a change: If a distribution has been certified as compliant, then it either IS compliant, or LSB organisation isn't worth a dime.
Which one is it for you?

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds