Re: Linux Foundation Collaboration Summit

[Zachary Kotlarek]

On Mar 19, 2008, at 1:52 PM, J. Greenlees wrote:

With the LSB:
Why would a BASE standrd not stop at the absolute minimum needed for a
functioning system? The addition of package management [ for example ]

[ I for one ignore the LSB because it is not what it claims to be, a

of extra software.

to the LSB has made in no longer a BASE standard. If extras are going to be included, then call it a Linux DISTRO Standard, not a Base Standard. BASE for Linux.] LFS and DIY are much closer to being a base in the lack

http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/book1.html

I personally don't care if LFS is ever LSB compliant. While it would be nice to be "compatible" I'm probably never going to just download some installer script and run it with root privileges -- it just scares me too much. I also have trouble imagining a scenario where non- LSB-compliant LFS wouldn't pass management's muster, but LSB-compliant LFS would. That being said, I think some of your complaints about the LSB are unfair. Maybe I'm missing something, but the LSB Core specification is pretty sparse: Obviously LFS wouldn't be able to apply the Desktop or other higher- level parts of the "full" LSB spec without a change in project direction, but the Core spec seems (to me at least) to have a reasonable scope.

Both sections need to be made as simple and clear as possible, with the

absolute minimum required for a functional system to be base system

Linux by commercial software houses, actually do nothing but polarize
the community, since they pick one package over another, to the
irritation of the supporters of the package(s) not picked.
The infamous Vim / Emacs holy war being a good example of what the LSB
is doing when they pick one package over another.

standard. The additions to the LSB, while meant to promote support for

The LSB does not require specific packages. It is an interface specification, and any software that provides the prescribed interface would be considered compliant. The LSB goes to great lengths to define exactly which symbols must be provided by each library, with the intent of allowing higher-level software to run reliably even if the underlying software is swapped out. I realize that in some cases there is only one realistic contender for a "compliant" library, and that is potentially a cause for concern. But on the other hand there's nothing stopping related software projects from implementing the required methods and becoming compliant themselves -- OpenOffice seems to do just fine supplying both an OLE file interface and its own native interface.

A specific suggestion re the package manager, remove the reference to

package manager is better. If the LSB just said packages must follow
this format

RPM in that section, and you remove the LSB from the dispute about which (format details as written, without reference to any specific package )

http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/swinstall.html

        Zach

Actually the LSB only says that compliant systems must be able to install RPMs. It does not say that compliant systems must use RPM internally, or even that the official rpm utility must be installed -- simply that packages in the RPM format must be installable. Moreover the LSB doesn't even require the entire RPM format spec, just a subset that's supposed to be moderately compatible. You can debate how "compatible" that subset is, but it seems to be working for Debian. Finally packages are only supposed to depend on the LSB specs, not on specific components, so you don't need to fill in the entire dependency tree. At least in theory you could just install the rpm utility, fake a couple of LSB packages into the dep tree, and call it a day.

smime.p7s
Description: S/MIME cryptographic signature

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page