Slashdot Mirror
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."
2 definitions found for imprimatur
From Webster's Revised Unabridged Dictionary (1913)
Imprimatur \Im`pri*ma"tur\, n. [L., let it be printed.] (Law)
A license to print or publish a book, paper, etc.; also, in
countries subjected to the censorship of the press, approval
of that which is published.
From WordNet (r) 2.0
imprimatur
n : formal and explicit approval; "a Democrat usually gets the
union's endorsement" [syn: sanction, countenance, endorsement,
indorsement, warrant]
The LSB FAQ (for those whose first question was "What the heck is LSB?")
One line blog. I hear that they're called Twitters now.
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.
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.
-- john
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.
Don't become a regular here, you will become retarded. -- Yoda the Retard
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...
.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...
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.
Anagram("United States of America") == "Dine out, taste a Mac, fries"
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.
I will certainly vote for the standardization of the use of the acronym tag on Slashdot...
giandrea
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."
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.
-Yenya
--
While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
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
> no automatic dependency satisfying
It's a package format. dpkg doesn't have it either.
> no "recommends"
> no "suggests"
It's a package format so expecting it to deal with dependency resolution is out of scope _but_ it does support it. Under RH9, install rpmdb-redhat and rpm will suggest resolutions for everything in Redhat's repository.
> no "conflicts with (anything other than its own
> other version)"
Huh? If RPM finds a file that it needs to write, it'll prompt if the file isn't in the database and will prompt with a "this package conflicts with x" if it is.
> no "provides"
--whatprovides and --provides
--whatrequires and --requires
> Harder source rebuild
rpmbuild -ba specfile
> no dist-upgrade alike
It's a package format/installer.
> no --simulate
Is rpm --test what you're looking for?
Andrew Cowie makes a pretty darn good argument for using Gentoo in a production environment:
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.
Preventive War is like committing suicide for fear of death. - Otto Von Bismarck
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?