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 ]
> 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.
> [ I for one ignore the LSB because it is not what it claims to be, a
> BASE for Linux.] LFS and DIY are much closer to being a base in the  
> lack
> of extra software.

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:
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/book1.html

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
> standard. The additions to the LSB, while meant to  promote support  
> for
> 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.

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
> RPM in that section, and you remove the LSB from the dispute about  
> which
> package manager is better. If the LSB just said packages must follow
> this format
> (format details as written, without reference to any specific  
> package )

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.

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

	Zach
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1682 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/lfs-dev/attachments/20080319/e5ba9a41/attachment.bin