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

LSB and rpm

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

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

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

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

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.

I have Debian servers at work.

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 so

At least the writer isn't biased.

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

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

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.

What problem

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

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

Re:What problem

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 "recom

Re:What problem

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

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 [linuxbase.org]

Of course, you [catb.org] know [wikipedia.org] who [helsinki.fi] is on record about how stop-gap measures "...have a way of staying around. Forever." [iu.edu]

package manager not the same as package type.

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.

Linux Standard Base

The LSB FAQ [linuxbase.org] (for those whose first question was "What the heck is LSB?")

No love given

"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

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 n

LSB will be valuable when...

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:How will this affect *BSD?

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?

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'

Re:ya but distros will just ignore it

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

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

Re:LSB?

Nope. It's called endianness.

Re:LINUX IS A LEGACY PLATFORM

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 [reference.com].