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

How will this affect *BSD?

[Cronopios (313338)]

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 (694581)]

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 (13932)]

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 (569062)]

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 (592662)]

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 (41445)]

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

[DenDave (700621)]

You should check LSB compliance from a distro perspective and not vice versa.

ftp://ftp.freestandards.org/pub/lsb/test_results

Re:LSB and rpm

[IamTheRealMike (537420)]

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 (27532)]

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 (537420)]

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'

Re:Debian

[Atzanteol (99067)]

Debian has "alien" I believe. And gentoo users can "emerge rpm" if necessary.

Re:Debian

[Alan Cox (27532)]

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 migh

I have Debian servers at work.

[khasim (1285)]

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 i

Re:Debian

[nadamsieee (708934)]

Andrew Cowie [linuxjournal.com] makes a pretty darn good argument [linuxjournal.com] for using Gentoo [gentoo.org] 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 "is

At least the writer isn't biased.

[nberardi (199555)]

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

Re:At least the writer isn't biased.

[infolib (618234)]

At least the writer of this article isn't biased. :)

Your smiley says it very well. The guy admits to being strongly biased, but he does it in a very open and slightly humourous way. I much prefer news written that way to cool "objective" "neutral" writing that's choc full of spin anyway - probably mostly unintentional. If nothing else we know where he's coming from.

Only if distros follow..

[ThisNukes4u (752508)]

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 (213815)]

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

[samjam (256347)]

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 (70654)]

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

[Wordsmith (183749)]

Well, that's the maintainer's fault. The maintainer should be making the dependencies generic enough to satisfy a default version of the target distro(s), as well as an upgraded version (unless the upgrade legitimately breaks compatibility).

The real problem is where upgrading X requires installing Y, which requires upgrading Z -- which is a buggy upgrade or which breaks other things on your system.

I've always thought the modern windows way of installing/uninstalling is more graceful. Install the app, with

Re:What problem

[vidarh (309115)]

So use apt for RPM, or yum, or any number of other dependency resolution tools.

As for whether or not the dependency is real, how is the way RPM defines dependencies any worse than how the Debian package manager handles them?

Re:What problem

[Zapdos (70654)]

Concept flies by=========> I didn't say apt is a good package either. While it is better than rpm it still sucks eggs. In the evil world when I install a program I install a program, not twenty.

Packages need to evolve to the next level where all dependencies are included in the package. Smart file version checking and safe removal are two items needed for the next package format. It will not overwrite a newer version of a file. It will not remove a file that is still required by other packages.

Aft

Abstration with "Provides".

[khasim (1285)]

With a Debian system, if something requires a "web server" (but not a specific one such an Apache mod), then the package can be built to depend upon a generic webserver.

The various web server packages can "provide" that.

So, in theory, any Debian package that depends upon a text editor can be built to use whatever text editor you like. Rather than requiring the text editor that the package maintainer prefered to use.

Re:What problem

[Vo0k (760020)]

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

I

Re:What problem

[Atzanteol (99067)]

Half of your problems have nothing to do with the RPM *format* and everything to do with RedHat's "rpm" command implementation.

Re:What problem

[Yenya (12004)]

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 (588495)]

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 (229616)]

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 h

Re:I don't agree with that.

[vidarh (309115)]

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 applica

Re:What problem

[sanityspeech (823537)]

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]

Re:LSB not so great

[caluml (551744)]

Mod this puppy up. But hey, if a little sacrifice is what it takes to make Linux easy and compatible for Mr Home User, so be it.

Re:LSB not so great

[Lussarn (105276)]

So I for one can't really advocate this.

Judging from the rest of your post if I aked you "Why" you would only answer "Because".

Re:LSB not so great

[crumley (12964)]

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 [kitenet.net].

package manager not the same as package type.

[gimpboy (34912)]

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

[AndroidCat (229562)]

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

Re:Linux Standard Base

[Ingolfke (515826)]

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

ya but distros will just ignore it

[by 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 (596332)]

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

[Antique Geekmeister (740220)]

Managing /etc/sysconfig alone in SuSE requires RPM's built specifically for SuSE, no one else's RPM's will work with their system management tools and vice versa until and unless SuSE gives up on everything being managed from YaST.

Frankly, they need to throw in the towel on YaST and hire a few webmin developers to give them a far more powerful, effective, and flexible tool that actually does the job.

Re:ya but distros will just ignore it

[cortana (588495)]

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

Debian knows better.

[xant (99438)]

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 pa

No love given

[by 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 (596332)]

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

LSB will be valuable when...

[Glasswire (302197)]

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 will be valuable when...

[grumbel (592662)]

5) When there is a painless way to build LSB-conforming binaries and packages. lsbdev and lsbcc might sooner or later provide that, but last time I tried I wasn't really able to get much done at all.

You've got my vote

[JDStone (741327)]

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

Country status

[Kickstart70 (531316)]

Have any countries given any indication that they are leaning in a direction for the vote?

Re:LSB?

[joto (134244)]

Nope. It's called endianness.

Re:LINUX IS A LEGACY PLATFORM

[aggieben (620937)]

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