LSB Submitted To ISO/IEEE

mcneil@freestandards says: "The LSB has been submitted to ISO/IEEE for an ISO imprimatur. While this is not really new news, it is important that every Linux user get involved to make sure their country votes YES for Linux ISO standardization! With Linux achieving international standards recognition it will be that much easier for governments and other risk adverse organizations to include Linux in their procurement policies. This of course will further the normalization of free and open source software, lessen the world's reliance on sucky legacy platforms, etc. etc."

Comments

How will this affect *BSD?

[Cronopios]

With Linux achieving international standards recognition it will be that much easier for governments and other risk adverse organizations to include Linux in their procurement policies.

How will this affect the posible use of FreeBSD by the government agencies?

Re:How will this affect *BSD?

[tuggy]

From linuxbase.org:

Is the LSB only for Linux systems and applications?
No. The spec has been written so it can be readily implemented on top of any UNIX-like operating system, natively or as a compatibility layer. There is also no fundamental reason why it cannot be implemented on other operating systems, although it is likely to be much more work. Note that this philosophy may be one of the reasons why a seemingly "obvious" Linux feature is not part of the specification if it raises needless barriers to implementing the LSB on non-Linux systems.

LSB not so great

[petrus4]

The LSB advocates RPM as the standard package management mechanism for Linux. To my mind that's a really bad idea...RPM has a lot of problems. So I for one can't really advocate this.

Re:ya but distros will just ignore it

[stratjakt]

Well, Redhat and SuSe are the ones who are actively trying to capture the corporate and government markets. Gentoo, Slackware, Debian, Ubunto, etc are not.

Only businesses really give a rats ass about ISO.

Re:LSB and rpm

[IamTheRealMike]

In theory yes. In practice, not really. There are a few blocking problems with respect to making LSB RPMs (if you are doing it to make things easier for the user and not for regulatory compliance or whatever):

• Out of the box none of the major desktop distros are LSB compliant as they don't provide the LSB release file or linker symlink. At minimum therefore the user has to locate and install the right LSB base RPM for their system
• LSB doesn't formally specify much stuff. Hardly anything in fact. C++ is out as various distributions (like Red Hat) decided they didn't want to standardise on a buggy g++ ABI, instead they wanted to break the C++ ABI yet again and get a bit closer to Itanium compliance. Desktop toolkits are out, unless you want to statically link the whole thing which whacks up theming and makes your memory footprint huge. Pretty much any other library is out as it's not included.
• You need to use their build environment. Not such a big deal this one but last time I tried it (a long time ago I must admit) most software didn't compile under it.

Because the LSB is currently so small it's pretty useless for desktop Linux software developers, and it doesn't attempt to overrule upstream goofs like NPTL so it would not prevent things like the Loki Games breakages.

I think it's useful mostly for big-iron server vendors right now - programs that don't need much stuff from the OS but must be certified.

Re:ya but distros will just ignore it

[cortana]

On Debian, installing 'lsb' from apt gives you a fully LSB compliant system.

Re:LSB and rpm

[Alan Cox]

Thats a fair summary on the whole although slightly inaccurate.

Several distros are LSB compliant by default (notably the enterprise ones). C++ is defined in the LSB but not in the ISO standard. The reason for this was that the C++ the LSB defines is interim but was needed. Many of us felt it shouldnt be in, and definitely not in the ISO spec since we knew it was transitional. The compromise was LSB defines a transitionary C++ (which will remain supported) and ISO doesnt

You don't need to use the LSB build environment - that is simply a tool for ensuring compliance.

LSB as you rightly say is about server software right now. A push on the desktop front has begun and hopefully things like gtk will get looked at. In addition there is an exploratory working group on java/jvm packaging and standards (java itself is obviously standardised elsewhere)

To get to the stage where you can go into a shop and buy packaged applications the LSB extending to desktop will be important. Many vendors don't stock Linux products because its too confusing in their eyes. At the enterprise level it doesn't matter for small business and home it does.

Re:What problem

[Qzukk]

RPM has better source rebuild than DEB.

(as part of apt-get source -b blender:)
dpkg-checkbuilddeps: Unmet build dependencies: ftgl-dev (>= 2.0.9-1) libglut-dev libopenal-dev (>= 0.2003011300-1) libsdl-dev python-dev scons

as for "Triggers", debian's got the better way, with the /directory.d/ concept outlined by someone else, as well as update-foo, and install scripts that do whats needed for them to work together. Or would you rather enumerate every possible package you'd want something special to happen on?

You cite the .spec file as magical goodness as if it comes with everything. I call debian/rules as even more magical goodness, since it can do most of what you claim (architecture-dependent builds, multiple patches, etc), and it comes with approximately the same number of tarballs (what, 3?). It expects you to know what you're doing, which is why Debian has a package maintainer for every package, and the Policy to tell them what to do. Additionally, you can use debian/rules to build only certain packages out from a multi-package source (like, say, just the php4-pgsql package from the php4 source).

The only thing I really don't like about the debian format is that by default they build packages with everything turned on, requiring that I install every possible library out there (a problem for something like PHP with 50 extensions I'll never use). Something like Gentoo's USE variable, without the arcane syntax and having to know what each library considers itself to be used as would be pretty cool (like say an ncurses list of checkboxes or just "build with libfoo? (Y/n).)

Not exactly sure what "%changelog" means to you, but debian's packaging system enforces having proper changelog entries.

So to wrap it up, the things that .rpm can do that .deb can't (or can't do in other, arguably better ways):
-Active use of package signing support (its supported, just not used in the current stable or testing distribution)
-Single .spec control file (Debian uses a directory of scripts and control files)
-More than one source tarball (I suspect Debian Policy probably prohibits this anyway - witness the number of pkgname-data packages for games and the like, and if the source cannot be built standalone, the maintainer would just include the other source in the debian .diff)
-Automatically build nonstripped library packages. (maintainer must specify this specifically)
-Verify script by default (some packages implement this on their own)

Debian knows better.

[xant]

Look, it's not just about apt. Even if it were just about apt, the people advocating apt being used with RPM are misguided.. the RPM package format lacks a lot of the functionality that dpkg has, and the system as a whole will suffer for it. But apt is only the smallest part of what makes Debian work well together. Pursuing "LSB compliance" will never produce a system that works as well as Debian.

1. There are hundreds of pages of manuals for covering every aspect of a Debian package's existence. As a package developer, this allows you to know, for sure how you should configure some particular corner of your package so it integrates best with the rest of the system.
   
2. Becoming a Debian developer is a process which takes up to a year, and occasionally longer, and tests in depth everything from the person's identity to whether they understand interactions between lib* packages.
   
3. Actually putting a package in the archive immediately subjects it to people who run automated test suites on it to make sure it is not going to conflict with the Debian way of doing things.
   
4. An open bug-tracking database is there to email package developers and let them know if they screwed up. The bug database is integrated into the system itself (via reportbug and friends), and people actually use it.
   

These are things LSB cannot replicate, and as a Debian user and administrator of commercial production servers, and soon to be a Debian developer, I have no interest in making Debian LSB-compliant.

GNU?

[rpsoucy]

Sorry, but I hope I never see a "Linux" standard that deals with anything other than the Linux kernel.

In all honesty, not enough thought has gone into creating a standard for GNU+Linux. I don't want to see good ideas like debian's package managment system go to waste because everyone decideds to make a bad descission and adopt RPM for package managment.

What about a standard GUI framework? Don't make me start up the KDE vs. GNOME vs. GNUstep fights :P

Standardization of BAD ideas would just hold back progression. An ISO standard might even make it so that ISO can legitimately charge money for Linux, ever think about that?

Who needs standardization, people will eventually gravitate towards the best, and that will be the standard.

Re:LSB and rpm

[IamTheRealMike]

The problem with not using the LSB build system is that GNU ld will automatically choose the latest glibc symbol versions (amongst other things) so you won't get a compliant binary out if you don't use it.

When I said "major desktop distributions" I really meant "popular desktop distributions" - while the enterprise distros will get a lot more important in future right now not many people use them.

The rest of your points are pretty much right. You have a more optimistic view of the LSB than I do, but we'll see how it goes ...