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.

Re:How will this affect *BSD?

[Asmodai]

Yeah sure.

Normative references to the Linux device list, init.d, run-levels, rpm as packaging, a bunch of user and group names that serve no purpose on other systems, and so on.

Please go fool someone else into thinking you can make it work on BSD, there's a reason why BSD and System V differ, because they are different architectural paths.

LSB and rpm

[OmniVector]

As much as I've used Linux, I have no idea how LSB helps per say. If two distros (lets say redhat and suse) both implemented LSB X.0, could I concievably use an rpm on both distros safely? Just curious if LSB guarantees this level if interoperability. If not, what the hell is the point?

Re:LSB and rpm

[grumbel]

You could use a LSB conforming RPM on both SuSE and Redhat, yes, but you could NOT just pick a random SuSE package and use that on Redhat.

LSB packages work basically completly independend from what the distro provides. If a distro is LSB conforming it only means that it can install LSB-rpms (by using alien on Debian for example), it does not mean that the distro itself consist of LSB-rpms.

Re:LSB and rpm

[CAIMLAS]

The point is this:

If I'm versed in the admin of one LSB-compliant distro, it's trivial to migrate to another (in most respects) as the location of config files and the like is identical.

That's trival, however, compared to the power of influence it will have upon both developers and people looking to adopt linux for deployment. If a distro is LSB-compliant, then developers will be able to write simply for all LSB-compliant distros.

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: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: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 ...

At least the writer isn't biased.

[nberardi]

At least the writer of this article isn't biased. :) "lessen the world's reliance on sucky legacy platforms, etc. etc."

Only if distros follow..

[ThisNukes4u]

While I agree that standardization is a good thing, it will only have an effect if distros follow. Right now, one of the most LSB compliant "distros" is Linux From Scratch, which is not exactly a mainstream distro. I know that others have been making strides towards compliance recently, but unless all distros follow it close enough so that one person can work effectivly on different distros without having to relearn its directory layout, it won't affect adoption as it is just another unfollowed standard (HTML, CSS 3 in IE anyone?).

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:LSB not so great

[crumley]

As others have said, deb and rpm really are quite similar. its the care that goes into making the debs and rpms that varies. Here's a nice comparison of package formats.

Linux Standard Base

[AndroidCat]

The LSB FAQ (for those whose first question was "What the heck is LSB?")

Re:Linux Standard Base

[Ingolfke]

The LSD Wikipedia (for those whose first question was "What got into the minds of the people who developed LSB?")

ya but distros will just ignore it

[Anonymous Coward]

Every distro thinks it knows best.

Debian doesn't do a lot of LSB stuff because it just thinks it knows better.

I'm sure gentoo and slackware are the same.

Basically Redhat and Suse will comply and all the other distros will not bother to meet the standard.

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:ya but distros will just ignore it

[cortana]

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

No love given

[Anonymous Coward]

"lessen the world's reliance on sucky legacy platforms, etc. etc"

Legacy platforms aren't sucky, they're just dated. Improvements on that technology have been significant, but unstable, thus the call for Linux standardization.

No insults needed on legacy, a concept that has been serving the PC community just fine for about 30 years.

Brooklyn.

Re:No love given

[stratjakt]

I don't know what they're trying to pull, but to me *nix is as legacy a platform as you're going to see.

Which is a good thing. Here's how you market linux to PHB's.

PHB's decomissioned all their old unix systems and bought Windows, thinking it would be newer and better and synergistic, blah blah blah. Instead they get a whole mess of various headaches.

So in comes Mr Pro-Linux Consultant, who says: "Hey, remember the computer system you had before this, you know, the one that just chugged along 24/7 and hardly ever had a hiccup? Would you like to have that again, on cheap, modern commodity hardware?"

It's not: "This is brand new vertacal entergraded synergistic paradigm! ISO! yay!"

What problem

[samjam]

what problems does RPM have?

If you can name any, how confident are you that these are not user-ignorance?

Finally, are you confusing RPM the package format with RPM the package manager? There is more than one RPM based dependancy manager just as there are many (and layers of) package managers for other package formats, e.g. deb.

Sam

Re:What problem

[Zapdos]

RPM Hell.
example.
In order to build a rpm package of the newest xmame you need sdl-dev
sdl-dev needs arts-dev
arts-dev needs kdelibs-dev
This in turn needs kdelibs, arts etc.

The real question, does sdl actually need arts? No it was a dependency question that was answered by the sdl-dev rpm package maintainer. The package maintainer must make decisions that are generic enough to suit the largest group of people.

Re:What problem

[Vo0k]

Okay, I don't know too much about internals of the RPM format, I was just an user of the RPM package manager, and it was a few years ago when I abandonned it, but what I've seen...

no automatic source selection.
no automatic dependency satisfying.
no "recommends".
no "suggests"
no "conflicts with (anything other than its own other version)"
no "replaces"
no "provides"
Harder source rebuild.
no "hold current".
no install-time configuration (some consider this advantage. I don't.)
no dist-upgrade alike.
no --simulate

It drove me mad when LILO required Linuxconf (and reading the config file I've seen comment like "# not really necessary, but why not?"), that packages that obviously needed ANY httpd, required Apache, ANY mailer required Sendmail, that with a dir full of RPMs which created a full dependency tree to install a package I couldn't rpm -i *.rpm but had to manually pick them from the bottom up, so before I install something, all its dependencies must be satisfied. And because of such bogosities I just kept abusing --force --nodeps ruining the integrity of the tree more and more. .deb has its problems. There are some conflicts that exclude half the tree, there are some dependencies that got lost and are unobtainable. But these are issues simple to fix. RPM on the other hand was causing problems I was just unable to fix...

Re:What problem

[sanityspeech]

Before the my-format-is-better-than-your-format debate kicks into high gear, it should be said that the LSB intends to use the RPM format as a stop-gap measure

Of course, you know who is on record about how stop-gap measures "...have a way of staying around. Forever."

Re:What problem

[Yenya]

Just FWIW, RPM has "conflicts" (with anything you want), "replaces" (obsoletes), "provides", "--simulate" (--test, actually). Source selection, automatic dependency satisfying, dist-upgrade, and probably others belong to a higher level than the package manager itself (yum, apt, up2date). The "recommends", "suggests" , and install-time config are deliberately missing, because RPMs are meant to be installable without an user attention.

RPM has triggers (script executed when other package gets installed/upgraded), %verify script, %changelog, automatically generated debuginfo packages, etc. Every file is MD5summed, package has MD5 sum, RPM supports GPG signature (and this feature is actively used by distros).

RPM has better source rebuild than DEB. It supports conditional compile (%ifarch, %if, etc.), so you can rebuild RPMs for several versions of a distro from one source package. It has a "BuildPrereq" dependencies. You can have more than one source file and more than one patch file, RPM makes sure you are compiling exactly along the lines written in the .spec file (so you actually get working and rebuildable source RPM, no manual editing/hacks behind the RPM's back). The build process automatically uses a subdirectory for installing files (so non-root rebuilds are possible). It warns you when you forget to package some file from the build root. You can even use a tarball instead of the source RPM, provided that the tarball contains the .spec file.

There is still one problem with using RPM: distro-specific macros. Last time I have checked, Mandrake uses %make macro, so you cannot take MDK source RPM and --rebuild it on Fedora, because you get "%make undefined" error.

Re:What problem

[cortana]

The Debian package format provides all the stuff you list as being specific to RPM. Except for a warning about forgetting to package a file that was built.

It seems the two formats are more similar than many people suspect.

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)

LSB will be valuable when...

[Glasswire]

1) All distros clearly say that their disro ver X is LSB ver Y compliant and stand behind that.
2) LSB mandates a sufficiently detailed configuration and fileset that a developer can build an app under any LSB ver Y.Z and expect it to install and run (with no missing libaries, re-configuration, config file editing etc) on any other LSB Y.Z compliant disro installation.
3) Oracle ver nn runs under LSB ver Y.Z NOT ONLY RH AS3.x and Suse EL 9.x (or whatever).
4) There's an automated validation that can determine if an initial distro install is (or is still) valid LSB ver Y.Z configuration.

Re:LSB?

[joto]

Nope. It's called endianness.

You've got my vote

[JDStone]

You've got my vote. I'll be contacting my national standards body soon to vote YES on LSB ISO.

package manager not the same as package type.

[gimpboy]

You are confusing the packaging method with the management method. The LSB states that the standard package _type_ is rpm. APT is package type independent. It is most _famous_ because it is used in debian, however you can use apt to manage rpms also. I am not advocating either package type, I just wanted to clarify the confusion between a method of packaging programs and the management of said packages.

Re:LINUX IS A LEGACY PLATFORM

[aggieben]

I nearly fell out of my chair reading that...too funny.

Good point though...Linux is per se a legacy platform, even though it has benefitted from lots of technological advancements.

One other thing I'd like to point out: there are no "risk adverse" organizations. The phrase the original poster was looking for is "risk averse".

See definition of averse.

I have Debian servers at work.

[khasim]

In short, Debian and Gentoo really don't belong in the corporate world, as they stand now. They're both more hacker-oriented anyways.

Riiiigggghhhhttttt..... While I find Debian to be the easiest to install, update and use and the stable branch is rock solid.

This is something only business/government really cares about. IBM et al are all behind Red Hat and SuSe, which are targetting corporate customers.

No. Quite the opposite, actually.

Businesses do NOT care about LSB-compatibility. All they care about is whether the ISV's app is certified on a particular platform.

The LSB is about making it easier for ISV's to write to the LSB which they hope the various distributions will support.

Re:Debian

[Alan Cox]

The LSB was very careful about this aspect of the standard

LSB compliance does not require "rpm" and it does not say anything at all about what tools are used to manage the base system. What it defines is a way to install a package in a given binary format (an RPM binary format subset). If the distribution only uses that for LSB packages or uses alien to convert it to dpkg first that is still just fine.

There had to be a single file format. Within that the goal has been to minimise the restrictins that might create.

Alan

Maturity

[SunFan]

lessen the world's reliance on sucky legacy platforms

This reeks of a teenager raving about Britney Spears vs. Lindsey Lohan. Either shut up or say something meaningful.

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.

Re:Debian

[nadamsieee]

Andrew Cowie makes a pretty darn good argument for using Gentoo in a production environment:

So how does Gentoo stack up in production environments? Here's another surprise for you from the source-based distribution: Portage can be told to build binary packages. This allows you to have one machine over in the corner doing all the compilation work. Then, the packages can be shared and used by all your target machines, instead of them having to build the packages themselves. You might be tempted to say "isn't that what the other Linux distributions do?" The difference is selecting the right mix of packages is a site decision, and the newer version problem definitely is a site burden to deal with. Gentoo gives local systems teams the tools to deal with solving these version issues themselves.

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:I don't agree with that.

[vidarh]

The PROBLEM is when an app is packaged via RPM and it REQUIRES a specific app that should have been sufficiently abstracted so that any server of that type could fulfill it.

As I've pointed out before, and as others have pointed out, this has nothing to do with the package format. RPM supports it. If you have a problem with a particular RPM based distro, then fine, but it's annoying when you keep on bashing RPM for something that has nothing to do with RPM.

I've already mentioned some fairly large applications that use this (Sendmail, Exim, Postfix all providing "smtpdaemon") for Fedora, but I stand by what I said about it being of relatively limited used simply because there are relatively few cases where applications are suitably interchangable that it makes sense.

You've not said anything to refute that other than make a loose claim that Debian use it a lot. Why don't you provide some examples?