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

Linux Standard Base

[AndroidCat]

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

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.

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.

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.