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

LSB - choose your defnition

[Anonymous Coward]

Least Significant Bit?

Re:LSB - choose your defnition

[alexs001]

Lower Side Band

Re:LSB - choose your defnition

[setagllib]

Least Sensical Bullshit.

This is a desperate attempt to minimize fragmentation between distributions. Anyone in their right mind would run a BSD anyway, which are internally consistent.

Honestly, this is yet another example of how the GNU/Linux world fucks things up and then requires a 'victory for open source' [e.g. this standard being accepted] to be anywhere near as sensible as a BSD.

Windows: Where do you want to go today?
Linux: Where do you want to go tomorrow?
BSD: Well now that we're here...

imprimatur

[Anonymous Coward]

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]

Re:imprimatur

[Anonymous Coward]

Thanks. That was great! Now do "cow".

Re:imprimatur

[Anonymous Coward]

Wow, that wasn't even remotely what I was thinking. I immediately read it as "imprimante". I couldn't figure out why the heck they needed to submit a printer for ISO approval...

Re:imprimatur

[Anonymous Coward]

4 entries found for cow.

Cow (kou)

n.

1. The mature female of cattle of the genus Bos.
2. The mature female of other large animals, such as whales, elephants, or moose.
3. A domesticated bovine of either sex or any age.
4. Your mom

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.

Re:How will this affect *BSD?

[ChTh]

Exactly. I'm starting to get a bit annoyed about Open Source always being equated with Linux and GPL. Open Source Labs, Open Source Developers Network. Open Source This, Open Source That, it's all Linux.

It's time we liberate "Open Source" from the shackles of Linux!

Re:How will this affect *BSD?

[archen]

Each BSD operating system (yes the whole damn system) is different but BSD derrivative. Because BSDs are an entire operating system, they do things their own consistent way and avoid the mess that LSB is trying to fix.

Now you could use LSB for a BSD distro, but why? Now you have something layed out like Linux but isn't linux, and you have a BSD that isn't layed out like a BSD. BSDs have a (usually) logical well documented heirarchy. LSB is a good thing for Linux with all the distros having things sprawled out all over the place, but is probably not for the BSDs.

Re:How will this affect *BSD?

[cthulhu11]

This sounds about as meaningless in the end as POSIX.

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

[DenDave]

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]

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

Re:LSB and rpm

[Anonymous Coward]

The point is that if I am selling some piece of closed source software, I can tell customers that it runs on LSB version X, and if their distribution supports LSB version X everything will just work. I don't have to give them source code to have them compile, and I don't have to worry about providing binaries for half a dozen different distributions and who knows how many different combinations of system libraries.

The LSB is about providing a uniform interface for binary applications across distributions. It is not providing a uniform system administration interface across distributions(as you seem to imply).

LSB?

[Enigma_Man]

The Least Significant Bit isn't standardized yet? Yeesh.

-Jesse

Re:LSB?

[macmastery]

No, it's Lesbian Super Babes!

Re:LSB?

[joto]

Nope. It's called endianness.

Re:LSB?

[Anonymous Coward]

As it happens - no. Sometimes it's the LSB of the first byte in sequence, sometimes that of the last. I'll bet there are a few applications where the whole bit order is transposed too.

Yes, I realise it was a joke.

Re:LSB?

[Anonymous Coward]

We don't care about your pet names for your penis.

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

Re:At least the writer isn't biased.

[Anonymous Coward]

Yeah, I mean calling linux a legacy platform. Sheesh, doesn't he know Linux was designed last year?

Re:At least the writer isn't biased.

[heavy snowfall]

Did it say anywhere when registering that the stories you submit had to be NPOV? (Neutral point of view). This ain't wikipedia.
They gy's allowed to have an opinion, in my opinion.

Re:At least the writer isn't biased.

[infolib]

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.

Re:At least the writer isn't biased.

[Anonymous Coward]

Well if a person is right and biased...

He is still right.

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

[Anonymous Coward]

RPM has a lot of problems. So I for one can't really advocate this.

And your opinion is important because...

Re:LSB not so great

[caluml]

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

[Shaman]

I'm with you. The Debian APT package management is in every way superior to RPM in my experience.

Re:LSB not so great

[Lussarn]

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

[Anonymous Coward]

I've read the other replies to this post, and they state the same point as mine, but much less obvious:

No dumbass, it's you who don't have a clue about how to use RPM.

Re:LSB not so great

[Anonymous Coward]

APT and RPM are to totaly different things. You probably meant that .debs are better than .rpm. But why is that?

Re:LSB not so great

[petrus4]

IMHO what someone should really do is finally implement a working version of ports for Linux, and submit THAT to the LSB. I got basic dep tracking working for my own little version of it a bit back...doing it nearly gave me a brain aneurism, but it worked. We'd want to do it actually with pmake, as well...not the (comparitively speaking) perverted abomination that is GNU make. ;)

Re:LSB not so great

[cylcyl]

Thank you! I was wondering why Least Significant Bit needs to be submitted to the IEEE

Re:LSB not so great

[Taladar]

I would rather have Mr Home User using Windows or some other crap and have the diversity of distros we had for the past years. Who the hell said every Operating System must cater to any users needs?

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.

Re:LSB not so great

[koreaman]

I have never used BSD, but from how people describe Ports it seems as though Gentoo's portage does basically the same things.

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?")

Re:Linux Standard Base

[pommiekiwifruit]

I already knew it was "least significant bit". Those newbie operating systems should pick their own TLA :-) OIIJSIMUJFIOS (otherwise it is just some idiots making up jargon for its own sake).

Re:Linux Standard Base

[Anonymous Coward]

Yeah, is this little endian or big endian? Is the LSB just the beginning, or does this mean everything else has been submitted already?

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

[Antique Geekmeister]

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]

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

Re:ya but distros will just ignore it

[Anonymous Coward]

Having a least common denominator like LSB may be a nasty idea for some people but its certainly nice to offer it as a choice.

With Gentoo it may be possible to implement the LSB through the USE-flag. For example if you need compliance just use LSB as a flag. If you think it sucks then just don't bother with it.

The same can be applied to other distros, too. It can be added as needed. If anybody needs ISO standard then just configure and compile it with the LSB flag. Some distros in the future may even offer a choice between ISO compliant and non-compliant binaries.

It does not have to be a Shakesperian "To be or not to..." decision. If its offered as a choice it will let the users decide whether its a good idea or not. If its good then it will become standard. If its bad then it will simply be forgotten.

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

Re:No love given

[stratjakt]

Just to add, the slogan should be: "Linux: All the UNIX you remember, with none of the vendor ass rape."

Re:No love given

[metamatic]

You mis-parsed the comment. It was alluding to specific platforms which are both legacy platforms and sucky.

Re:No love given

[SunFan]

People went to Windows because they hated UNIX. Now, they are going to UNIX, because they hate Windows. The software industry sucks, doesn't it?

Re:No love given

[DuckofDeath87]

I read that statment as lessening the reliance on the legacy platforms that suck, appose to lessing the reliance on legacy platforms, which suck.

The differance is the frist one does _not_ say all legacy platform sucks, but we will no longer be reliant on the ones that suck. Whereas the second one says legacy platforms suck.

English can be very confusing.

Debian

[GtKincaid]

So with RPM being the official standerd where does this leave distro's based on debian , or even gentoo.
I personaly am a debian user and thus a little biased towards dpkg and havnt been a great fan of rpm .

Debian has many comerical offspring and a vast array of other distros which use the dpkg /apt-get combination .
Having RPM as the official standerd dosnt mean that debian would have to change its packaging system but i see this causing problems for those debian based distros in the bussines sector!

Re:Debian

[stratjakt]

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

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

Re:Debian

[DJProtoss]

both debian and gentoo can cope quite happily with install files supplied in rpm format (debian via alien and gentoo via a couple of options in the ebuild).

Re:Debian

[Atzanteol]

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

Re:Debian

[WWWWolf]

RPMs have never been a problem for me.

Debian folks often think RPM is inferior packaging format. Of course, it is, if you're going to build a coherent distribution. But it is a good format if you're distributing third-party software. Why is this so? RPM depends are primarily libraries which can come from anywhere. Debian's depends are primarily other packages, hopefully ones from your distribution, possibly not.

There's always alien. "alien whatever.rpm" will generate just beautifully compatible .deb package. And you can always use Alien to generate a tarball out of .rpm. And there's always the "repairing with vi and toothpick" option: RPMs are actually cpio(1) files with a funny header. (.debs are ar(1)-glued tarballs. Slightly easier to extract than cpio files, in my opinion.)

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

Re:Debian

[Taladar]

But Gentoo users would never do that because rpm sucks.

It is the reason most of us went away from redhat, suse or other rpm-based distros in the first place.

Re:Debian

[0racle]

RPM checks the RPM database for packages that provide other libraries, simply having the library available does not allow you to install an RPM that requires it. The dependancies for an RPM are worked out the same way they are for debs. That is unless something has changed in the past few years, I haven't used a RPM based distro since Red Hat 7.3.

Re:Debian

[Anonymous Coward]

It is the reason most of us went away from redhat, suse or other rpm-based distros in the first place.

ym --funroll-loops

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.

Re:Debian

[nadamsieee]

If a package install requires an rpm for some strange reason, the ebuild can be made to handle the rpm. So the end-user never needs to deal with the rpm, just the ebuild maintainers.

Re:Debian

[Atzanteol]

Well, that's rather what happens. I actually had an .ebuild that required rpm to be installed. I forget what it was, but that's when I found out that rpm exists for Gentoo.

I believe the .ebuild downloaded a .rpm and used rpm to extract files from it or something. *shrug*

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

[gimpboy]

The package maintainer must make decisions that are generic enough to suit the largest group of people.

So how does this situation change when the package maintainer decides to make a debian package? I don't see how changing the package type would alter the dependencies?

Sure downloading the dependencies might be a pane in the arse, but you can use apt4rpm to handle that for you.

Re:What problem

[Wordsmith]

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 any needed shared libraries (leaving older versions in place if need be). When it comes time to uninstall, ASK the user if libraries potentially used by multiple apps (that don't actually appear in use by anything) should be removed. Don't tie huge clumps of files into single packages that can only be installed/removed in one lump.

Re:What problem

[vidarh]

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

[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

[Zapdos]

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.

After this then LSB will be ready for mass approval, not now.

Re:What problem

[Atzanteol]

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

[petrus4]

The main one that I can think of, off the top of my head, is that the specfile/macro format is obtuse, utterly abominable to work with, and encourages sloppy coding. Then there's the truly awful practice of downloading binary RPMs from who knows where...Great security there.

Re:What problem

[RogerWilco]

I've been using SuSE and YaST since version 6.2 (1999 or there about) and although it also uses rpm, it also does exactly all the things you list AFAIK. I haven't ran into a problem yet, but have mainly used .rpm's provided by SuSE, maybe a handfull others.

It's the reason I keep buying their CD's/DVD's every now and then (6.2, 7.1, 8.1, 9.1). Esp. before I had DSL, ftp was just to much of a hassle, if nearly everything can be bought on 2 DVD's at the shop around the corner.

Re:What problem

[vidarh]

I don't agree. I don't want 50 versions of some library on my system just because it makes package maintenance better. But if that is what you want, NOTHING is stopping packages from including everything it depends on. The reason it is rarely done is because there's rarely any need to do it.

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

[Fred_A]

And the moronic packaging made by some. It's gotten better though.

And regarding RPM, well, the wrappers take care of most of that. urpmi, yum (presumably, never used it), etc.

This being said, there is no perfect solution. Once the system gets complex, things do break every now and then.

Re:What problem

[cortana]

Look, you're never going to be able to convince the static-linking-luddites. Just give up. :)

Re:What problem

[KiltedKnight]

You could potentially beef up security a little bit if you require people to use the GPG key portion. Anyone who distributes stuff on-line, would have to get stuff certified by a key provider. The key providers would distribute their keys via either a CD mailed to you or via https download. Any system that would be using LSB would then have to mandate that a package pass the digital signature(s).

It's not much, but it's a start. Any one item you do is not going to guarantee anything, but it will lessen the chance that it's something insecure.

Besides, if you're patching your production boxes directly from some download site without first testing the affects of patches on your systems, you deserve what happens to you.

Re:What problem

[vidarh]

First, nobody is forcing you to download binary RPM's from who knows where. However, the very purpose of a "standard" packaging format is that that is exactly what most users want. To make that less painful and risky, RPM's can be signed, but you still won't get around the fact that users WANT to be able to install and run binary packages from "anyone". Deb's allow the same thing, and source is no safer unless you inspect it, which the typical binary package installing user is never going to consider. What do you suggest as a safer solution?

As for the specfile format, that is quite close to the equivalent file for .deb's as far as I can see. What specifically do you have a problem with? I agree the macro format is horrible, but how many people EVER get in a situation where they need/want it? I've written a large number of specfiles over the years, but I've never ever felt the need to use macro's. Can you point me to an example where using the macro's would be useful where the macro format makes it more complicated than need be?

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

[metamatic]

See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?i d=73097

RPM has been broken for years. RedHat's official answer seems to be that you should just delete and re-create the RPM database every time you use RPM, if necessary. (It was on a system I had.)

Re:What problem

[vidarh]

Why then is triggers not allowed in LSB compliant packages specifically in order to maintain compatibility with Debian based systems? Or is that a restriction due to limitations of Alien and not the .deb format?

Re:What problem

[cortana]

I don't know what RPM triggers are, but a cursory Googling indicates that they are similar to the {pre,post}{inst,rm} scripts found in debs. Perhaps the typical contents of an RPM trigger are too dissimilar to a postinst script for the same script to work on two different distributions?

Re:What problem

[Yenya]

RPM has {pre,post}{inst,un} scripts, which are called when the package is installed/upgraded/removed. Triggers for a package is a script which is called when some other package is installed/upgraded/removed. Think adding your daemon to some startup script of another package.

Re:What problem

[Yenya]

The Debian package format provides all the stuff you list as being specific to RPM

Last time I have checked DEB packages weren't GPG signed and did not contain MD5 sums of every file in the package (altough I think I have heard that the package format supports this; it is just not widely used in Debian distro). There were no debuginfo packages. No rebuilding from a taball with .spec (or what) file included. No triggers. Are you really sure everything I have mentioned is really in Debian/dpkg too?

I can throw some more features in, when I remember - e.g. what about the "Nosource" directive (i.e. make the .src.rpm without including the source tarball itself, maybe for licensing reasons)?

Re:What problem

[cortana]

> weren't GPG signed

There are two ways that this is done in Debian, IIRC. The first way is to sign the actual .deb file itself. This is used to confirm the authenticity of a particular package, and the checking is done by the debsigs package.

The second way is to sign the Release file that each Apt repository provides (the Release file contains a cryptographic hash of the Package files, which contain hashes of the individual packages). You can start digging down the chain of trust from http://ftp.uk.debian.org/debian/dists/sarge/, for example.

This second method is used to ensure that a given package is part of a given release of Debian, so you can be sure that the package you are installing has not been obsoleted by, say, a security update. Now, for some reason, the version of Apt that comes with Debian doesn't do these checks, you have to pull Apt 0.6 from experimental. I guess it will be uploaded to Unstable once Sarge is out.

> MD5 sums

Most packages generate MD5 sums at build time. You can configure dpkg to generate missing md5sums at install time if you want.

> There were no debuginfo packages.

Packages with debugging symbols? There are plenty; look for, eg, libc6-dbg. Obviously, it's up to the package maintainer to create such packages along with the more usual libfoo and libfoo-dev packages.

> No rebuilding from a taball with .spec (or what) file included

Not sure what you mean by this. The say to rebuild a set of binary packages is to download the source package (consists of a .dsc file, a tarball of the sources and a patch). You then install the source package's build-depends (specified in the source package control file). Finally, you run the build script to build the package.

This process can be automated to a greater or lesser extent according to your preferences. I prefer to run apt-get source, apt-get build-dep, fakeroot debian/rules binary manually, I think DDs tend to use dpkg-buildpackage because it does extra stuff that they need to do in order to upload the result, like signing the packages with Gnupg. There is even a tool, apt-build, that automates the entire process, including compiling build-depends as well, all with customisable compiler flags, etc etc. Useful for people who like Gentoo, maybe.

> "Nosource" directive

If I have a correct understanding of what this is for, the way it's done in Debian is to remove the files from the upstream tarball, before uploading the source package. I can see why specifying the files you don't want included somewhere else, and having them removed after the fact, is useful; however Debian packages must be freely distributable, and so uploading a source package containing undistributable files is not allowed.

Re:What problem

[cortana]

Ok, dpkg can't do this. However at the risk of sounding like a pompous twat, it sounds liek the kind of thing that shouldn't be necessary if you factor the operations that your packages perform correctly in the first place. :)

A Debian package that could be extended with other packages would tend to use a method more along the lines of this: /etc/init.d/foopackage sources all scripts in /etc/foopackage.d/
barpackage contains a file: /etc/foopackage.d/barpackage.sh

FYI, barpackage would then probably declare Enhances: foopackage in its control file, but that's not directly relevant to the above.

Re:What problem

[Aeiri]

Packages need to evolve to the next level where all dependencies are included in the package.

Okay, so say a Nicotine package would need:
Python
PyGTK

Let me tally that up. The original size would be 2MB, with your method that would be.... 65.15MB.
Cool.

Re:What problem

[Zapdos]

Who said anything about 50 versions? That is your assumption, and has nothing to do with what I stated.
This is the purpose of smart version checking.

Re:What problem

[SunFan]

what problems does RPM have?

One problem is that its man page is a thousand pages long with 950 pages of options that matter to practically no one.

Re:What problem

[Anonymous Coward]

Ever uninstall ppp on a default Woody? Ever see that 'rm -rf' flash by? And you think RPM encourages sloppy programming?

RPM is strict. It implements policy in code as opposed to encouraging the package maintainer to script what they believe the policy should be into pre- and post-installation scripts. RPM caters to the administrator whereas dpkg caters to the package creator.

As for security, RPM supports signing and Debian users have a number of external repositories to download.

Re:What problem

[Taladar]

Bad idea. How do you prevent old libraries with security holes on your system with this?

Re:What problem

[Taladar]

That is another thing most rpm-based distros never get right.

You have to upgrade your system with CDs every once in a while instead of simply upgrading by downloading the newest versions of your installed packages.

Re:What problem

[dodobh]

Hmmm, provides is definitely there.

And please do not compare RPM to apt-get.
RPM is equivalent to dpkg.
YUM/URPMI/up2date are equivalent to apt-get.

Of course, nothing matches portage, or BSD ports.
cd /usr/ports/mail/postfix-current && make install replace is hard to beat :)

Re:What problem

[vidarh]

Regardless of your hypothetical "smart version checking", I'd rather not have every application that needs all the Gnome libs, for instance, ship with the 11MB of stuff I already have that makes up /usr/lib/libgnome* alone on my system, thank you very much. Not to mention the X11 libs, and glibc, and all the other dependencies most of them have.

All Linux packagers have the option of doing what you want NOW by simply including the libraries they prefer in each package, and have a wrapper script to set the preferred library loading path and include scripts in their packages to install only the libraries needed. They aren't doing it because most people consider it a tremendous pain in the ass and more trouble than it's worth.

My wild guess of 50 copies of a library aside, if the number is low, then the NEED for what you suggest isn't likely to be there either, because if so it would demonstrate that the number of incompatible library versions that users are likely to have to deal with is low as well.

Re:What problem

[Anonymous Coward]

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

Re:What problem

[Wordsmith]

When the update comes out, make part of the install the (optional but highly recomended, with the GUI giving the user the choice) outright replacement of the old version with the new version. When an update doesn't fix anything critical, have it simply install itself alongside the old version.

Re:What problem

[Yenya]

Most packages generate MD5 sums at build time.

So the packager have to do something special to generate MD5 sums? What if he forgets to do it? What if his script is not correct? RPM does this for you automatically.

Packages with debugging symbols? There are plenty; look for, eg, libc6-dbg[...]

No. RPM's debuginfo packages are created for every package automatically. So you can have debugging symbols for just any package you want. Not only libraries. When some customer (or user) have a problem with your package, you can tell him to install the debug informations and the n to send you the output of GDB or so. The point is that you have the debugging symbols created, but not installed by default (since they take the disk space). And again, the main advantage is that RPM does this for all packages.

>No rebuilding from a taball with .spec (or what) file included

Not sure what you mean by this.

With RPM, you can download the tar.gz file from the upstream site, and run "rpmbuild -ta .tar.gz". If this tarball contains the .spec file, the binary RPMs will be built (so you don't need to distribute a separate tar.gz and src.rpm files when you are both maintainer of the project itself and its RPM packaging).

Re:What problem

[vidarh]

Actually, I have twice now upgraded Fedora Core boxes by changing my APT repository and doing a dist-upgrade.

I did the same from Redhat 6.2 straight to 7.3 once (again with apt-get). THAT was painful, but it worked (after I reran apt 3-4 times).

It's been getting steadily better, but there's still a lot of work left before I'd recommend anyone to try it without a backup, or a bootdisk and a lot of patience :)

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)

Re:What problem

[Anonymous Coward]

RPM dependencies are not fine-grained. You either depend on a package, or don't mention it. Debian packages include dependency types required, suggests, recommends, conflicts, and replaces along with ways (options) to install a package with or without the suggested or recommended packages. This is useful for allowing a user to install a core set of features while allowing another user to install a full set of features. (Think about a configuration program that works without a web server or X11 GUI; headless machines admins can install the minimal while others can install a web server and X11 environment with the package.) The real dependencies are listed, while the optional (functionality-enhancing) packages are also listed. Developers don't have to decide whether or not feature x is so important that it should be required for a package.

Re:What problem

[Zapdos]

Still missing the picture.. I guess the box is pretty hard to get out of.

The version checker could check which individual files need to be downloaded and download and install only those? "This is not the only way it could work."

If Linux is to really grow beyond a technical niche market it will have to change it's package management. Until Linux has a unified package management system that simply works, you will not find more than a very small amount of commercial application development for Linux.

How hard is it to support Linux Boxed programs?
Think about all of the people who bought WordPerfect for Linux, will they be able to install that application on their New Linux box? Think about all of the games that Loki ported, when is the last time you tried to install one of those? No commercial software vendor wants to rewrite an application just because of a glibc update.

The net results of the current package management systems is:
1. Linux will not be for Joe User
2. Linux will have limited commercial applications for Joe User. Try to find a greeting card program for Linux?

Re:What problem

[cortana]

> So the packager have to do something special to generate MD5 sums? What if he
> forgets to do it? What if his script is not correct? RPM does this for you
> automatically.

If the packager is using CDBS then it is done automatically. If the packager is doing stuff manually then they are generally intelligent enough to place dh_md5sums in debian/rules. This is even the default for a skeleton rules file generated by dh_make.

> No. RPM's debuginfo packages are created for every package automatically.

Cute, that sounds useful. I guess Debian doesn't do it either because no one has asked about it, or because it is hairy to generate such symbols across Debian's 11 architectures or something.

> With RPM, you can download the tar.gz file from the upstream site, and run "rpmbuild -ta .tar.gz"...

Well this is just a case of whether you include the .spec file, or debian directory, in teh upstream archives, isn't it?

An upstream package developer is free to include a debian directory inside their own releases; ndiswrapper is one package I use where upstream does this. Of course, in almost every case this directory is removed and replaced by the Debian maintainer of the package, since usually upstream's attempts at a debian directory are sorely lacking.

If you are both the developer and packager then you have two choices:

Create a 'debian native' package. Native source packages dontain only an orig.tar.gz. This is for packages native to Debian, where it doesn't make sense to have a separately maintained debian directory, such as apt or dpkg.

If your package is not specific to Debian, then you should separate your roles as developer and maintainer, and keep the contents of your debian directory out of your 'upstream' releases. In this case, your 'upstream' releases become the .orig.tar.gz archive, and your debian directory it stored in the per-Debian-revision .diff.gz file.

Re:What problem

[vidarh]

The version checker could check which individual files need to be downloaded and download and install only those.

So in other words what you want is dependency resolution, as provided by Apt, Yum, Urpmi and several others. What features of Apt for instance is it you think you need? So far what you have mentioned is stuff that is already there, and in use, by most modern distros. And if you want application local libs, you can trivially do that by using pre-install scripts to pull down additional packages.

As for Loki games, I've reinstalled several Loki games several times through many major distro updates, without any problems. Whenever you find apps where you do run into problems, they can usually be solved by having multiple versions of the RPM installed at once. RPM supports it. Some tools supports it better than others. So far, I've heard very few users actually bring this up as anything but a hypothetical situation - it's a concern that mostly affects closed source apps, and few Linux users rely on old closed source Linux apps as they tend to be left in the dust fairly quickly.

However, I challenge you to point out a single feature of the current package management systems that prevent you from shipping whatever set of dynamic libraries you want with it, if you do want to go to the trouble of copying how it's done on Windows. If what you want to do is treat the package manager as an archiver with a method to run a script, you can.

So what are you complaining about? As I've pointed out, the package management systems supports what you have suggested, so should I assume what you're complaining about is the package maintainers who apparently doesn't agree with you?

Re:What problem

[Blakey Rat]

Rarely done? Every user of MacOS X does this every day of every year, and it works great... aren't Slashdot posters constantly raving about OS X's ease-of-use?

Re:What problem

[SnarfQuest]

Sure downloading the dependencies might be a pane in the arse,

A window in the butt? Sure, it may sound very poetic, but I don't think I've ever heard of anyone successfuly putting a whole sheet of glass there.

Re:What problem

[vidarh]

Rpm also allows you to list packages that conflicts. So that leaves suggests and recommends. I'm not so sure that is functionality that adds a net benefit (since it could easily have been provided in the documentation), though at last someone have actually managed to suggest something Debian packages has that RPM's doesn't (to my knowledge anyway).

Re:What problem

[vidarh]

Talk about taking out of context. The discussion is about the packaging of Linux applications vs. formats such as RPM and DEB.

Re:What problem

[Zapdos]

I guess the concept is too far out for you.

Re:What problem

[vidarh]

And that is also usually how it is structured in Fedora.

Triggers are useful in more complex cases. Say I have application A and application B. They don't depend on eachother to work, but application A provides additional functionality that application B can make use of if available. Application A is useful without application B and the two may be completely unrelated, so it shouldn't require B. Application B requires configuration data that tells it where to find application A if present, and application A might be retargetable, so it might not be present in a fixed location.

Either you let the user handle the configuration, or you make application A know about application B and provide the configuration data, or you let application B look for application A whenever it could make use of it, possibly using the package manager to look for the location of the files it needs, and ignore it if it isn't present, or you use triggers to let application B's configuration be upgraded when application A is installed.

In a situation like this I'd argue that triggers might be the cleanest solution. But it's not as if they do anything you can't do in alternative ways.

Re:What problem

[Zapdos]

Which package manager will see that fungame.x.x.deb/rpm needs libsquat.x.x.so.3 and will install the 3K libsquat.x.x.so.3 file not the 32M squat.x.x.deb/rpm

Which package manager when doing an uninstall of fungame.x.x.deb/rpm will just remove libsquat.x.x.so.3 when it is no longer being used by any program?

Wait a minute this system already has libsquat.x.x.so.4 that is compatable with fungame.x.x

Maybe now you see?

Re:What problem

[RogerWilco]

You don't have too, it's perfectly possible to install SuSE over ftp, or even only update certain packages. This is what I did between some CD/DVD versions I bought. It's just convenience, pop in the DVD, select what packages you want, go drink some coffee, and 30-40 minutes later you have a working system, network, WiFi, right kernel (smp), etc.
In the past 5 years I maybe 10-15 times used an rpm that wasn't supplied by SuSE, and those installed with YaST correctly too.

Some other reasons I used CD/DVD's :
- until recently I only had a modem, not DSL, so getting 7-8 CD's or 2 DVD's with software was really nice.
- At work I do not have internet access with my own system (P4 laptop!) so being able to install missing programs from DVD is still occasionally handy. (work also uses SuSE 9.1, but I am not root there, and asking the IT dep. sometimes just is to much hassle.)

I don't use it because I can't do anything else, but for convenience, __it just works__.

Re:What problem

[Dwonis]

So the packager have to do something special to generate MD5 sums? What if he forgets to do it? What if his script is not correct?

apt-get install debsums

Re:What problem

[samjam]

whereas .debs have multiple programs and alternative addon programs to manage it all, with overlapping capabilities leaving puzzlement as to which application is more suitable for a particular aspect of package management.

Am I the only one for whom dselect on a testing/unstable tried to un-install most of kde, followed by (after crafty refusal) most of gnome?

dselect had the various packages selected but "dselect, install" felt the need to remove them.

apt-get install on all the "de-instal candidates" managed to restore their keep status an in the end some single library as updated asa result (gah, forgot which one).

I merely mean to point out that there is no great reason to find rpm as a format any worse than the rest. Most package management schemes implement the same abstract capabilties.

Sam

Re:What problem

[mrchaotica]

I don't have experience with Debian, but I think I understand what he's talking about. "Suggests" and "recommends" function sort of like Use Flags in Gentoo. Here's how those work:

Let's say I want to install xmame, like the original poster. If you want to use arts and KDE, you'll set USE="arts kde" and it'll treat KDE as a dependency to xmame and install it for you. If, on the other hand, you DON'T want to use arts and KDE, you set USE="-arts -kde" and it won't.

By the way, since Gentoo is source-based, this means that the function calls to the kde libs and whatnot won't even be compiled into xmame if you don't want them to be (which I think is good).

Re:What problem

[Vo0k]

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.
Yes. Only during install. Not at package selection time. Last time I checked, even --test didn't support that (that's what I meant no --simulate)

--whatprovides and --provides
--whatrequires and --requires

These show file ownership, not package dependencies.
Debian "provides" is something that allows you to install any demon that does certain task satisfying all dependencies on this particular kind of service without specifying the particular package that provides this service. In RPM it's notorious that package a) depends on Sendmail, package b) on Postfix and Postfix conflicts with Sendmail (on some files) so I can't install both a) and b) from RPM. Of course if I download a) and compile it from sources, it goes smoothly along with Postfix. It was just the packager who decided Sendmail is necessary, not ANY mail demon.

Re:What problem

[JamesHenstridge]

In many cases, a library will require some other support files at runtime. Unlike dynamic linker dependencies, there isn't a reliable way to find out about these requirements. The common way to handle this is to combine the library and support files into a single package that is installed as a single unit (or include a dependency on the package containing those support files).

Now in the case of a small "libsquat.xx.so.3" being part of a large package, if the library doesn't require all the files in the package, and the library is intended for use by other programs a linux distro will usually package the library separately with only the files it requires, and make the larger package depend on the library package. If there are particular instances where this hasn't happened in your distro, perhaps you could try filing a bug.

As for recursive package removal, it is fairly trivial to find all the leaf nodes on the package dependency tree that could be removed without causing an inconsistency, but it isn't easy to tell whether it is safe to remove said packages. Which leaf packages is the user actually using? The user may be using some packages that may have been installed to satisfy dependencies, so you can't just remove packages that weren't explicitly installed by the user.

Lastly, if "fungame" requires libsquat.xx.so.3, then libsquat.xx.so.4 would _not_ satisfy that dependency. If two libraries have different sonames, then they provide different ABIs (they use different filenames so that you can install them in parallel to satisfy the dependencies).

Overall, the features you've brought up are already available in the current generation of package management systems -- you just want finer grained packaging.

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

[grumbel]

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.

Re:LSB will be valuable when...

[Anthony Liguori]

1) All distros clearly say that their disro ver X is LSB ver Y compliant and stand behind that.

The major distros (SuSE and RedHat) do this.

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.

Have you read the LSB? This is what it does.

3) Oracle ver nn runs under LSB ver Y.Z NOT ONLY RH AS3.x and Suse EL 9.x (or whatever).

You're never going to see this. Why? Because of testing. Since there's no "LSB" distro to test on, Oracle can only test on things like AS3.x and SuSE EL 9.x and therefore will only certify that it works on what it's tested on.

However, if it works on one LSB compliant distro, it should work on another. Keep in mind though, not everything is covered in the LSB. Otherwise, there'd be no point to having a distro, we'd all just use the LSB.

4) There's an automated validation that can determine if an initial distro install is (or is still) valid LSB ver Y.Z configuration.

There is. My office mate over the summer was an intern hired to run this test suite against various distros. I think you have to be an LSB member or something to get to it though.

Re:First Post

[Anonymous Coward]

don't worry neither does our president

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.

LINUX IS A LEGACY PLATFORM

[stratjakt]

For fuck sakes. Unix is nearly 30 years older than Windows NT.

Statements like this are the reason people troll. Slashdot has become a joke in the true "geek" world.

You are zealot morons who know nothing about computers.

"legacy platforms". Asshats.

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:LINUX IS A LEGACY PLATFORM

[Anonymous Coward]

Statements like this are the reason people troll. Slashdot has become a joke in the true "geek" world.

No. The reason people troll is because they feel powerless in the real world, and can exercise some degree of anonymous control here by derailing discussions.

Learn to play a musical instrument, and get a pet or two. You'll feel much better.

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:WtF?

[rbarreira]

Well, if it helps, I also thought about least significant byte when I read that :P

It doesn’t help per say

[Pan T. Hose]

As much as I've used Linux, I have no idea how LSB helps per say.

It doesn't help per say, but some people need it: the government, big business, et caytera.

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:I have Debian servers at work.

[Llanfairpwllgwyngyll]

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

Absolutely. Same here.

Patch all your corporate critical systems quickly from a local apt-mirror? Job jobbed...

Re:I have Debian servers at work.

[tolan-b]

> Patch all your corporate critical systems quickly from a local apt-mirror? Job jobbed...

Just like Redhat and Suse you mean?

Acronym Tag

[Anonymous Coward]

I will certainly vote for the standardization of the use of the acronym tag on Slashdot...

giandrea

RPM??? Why Take Over The World...

[Anonymous Coward]

when you can just shoot yourself in the foot - again, and again, and again...

WTG Linux community!

Ob Grammar Pedantry

[Anonymous Coward]

I have no idea how LSB helps per say

I have an idea how it helps per se.

Re:Ob Grammar Pedantry

[Anonymous Coward]

even more pedantic: per sé

Re:Ob Grammar Pedantry

[menkhaura]

"Per se" comes from Latin and it means, literally, "by itself". Latin didn't have diacritics. Where did you pulled this "sé" from?

Country status

[Kickstart70]

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

LSB to influenc PAM in Slackware?

[CatsupBoy]

So what chance does the LSB have in influencing Patrick to introduce PAM into slackware?

Or does the "Simple" in the Slackware model indicate "we 'Simply' dont bother with ISO standards"?

I love slackware, but find it slightly annoying that PAM is never an option.

Re:LSB to influenc PAM in Slackware?

[WMD_88]

Patrick V. hates PAM. He's known to refer to it as SCAM ("Swiss Cheese Authentication Modules") and dubs it less secure than Sendmail.

I doubt it's going in anytime soon.

PS: I, a Slackware user, have never had any trouble with PAM not being there. I don't even know what the thing does. :D

Re:LSB to influenc PAM in Slackware?

[CatsupBoy]

PS: I, a Slackware user, have never had any trouble with PAM not being there. I don't even know what the thing does. :D

Yeah, hence the "slightly annoying" comment. There are just a few things i've had to have PAM for, namely ACE authentication (SecureID).

I've been running my home servers on slack for some time and havnt encoutered any show stopers yet due to lack of PAM.

However, public influences are not totally free from Slackware (think v4.x -> v7.x). So I'm just curious to see if something like an ISO certified LSB would persuade Patrick into conforming in order to stay a primary linux distribution.

Abstration with "Provides".

[khasim]

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:Abstration with "Provides".

[vidarh]

Provides is supported by RPM as well. In fact, I believe the syntax for the package maintainer is exactly the same, but my experience with .deb's is limited so I might be wrong (for RPM you write "Provides: whatever-capability" in the spec file, and that package can satisy the dependency of any package that contains "whatever-capability" in the "Requires:" line).

Single UNIX Spec?

[Darren Bane]

Can someone enlighten me about whether or not the LSB is a strict superset of the SUSv3 ( http://www.unix.org/single_unix_specification/ )? Thanks.

Finally, the precision I need!

[Anonymous Coward]

Its tough to calculate stuff not using the least signifigant bit

Why haven't they done this already?

[khasim]

I can't seem to find a public discussion of what FEATURES or FUNCTIONALITY they are looking at for package management.

I see their page about RPM's and how they are a temporary measure and what functionality they do NOT want.

And package management is, to me, part of the core functionality.

That way, different distributions could implement ADDITIONAL functionality, as long as they also had the core LSB functionality.

Verify that "Provides".

[khasim]

Just FWIW, RPM has "conflicts" (with anything you want), "replaces" (obsoletes), "provides", "--simulate" (--test, actually).

Do you have an example of the "Provides"? I haven't seen that yet.

Re:Verify that "Provides".

[vidarh]

What do you want an example of? It works exactly like in Debian, allowing you to specify a "virtual" package name/capability that the package in question can be used to satisfy.

Any examples of .rpm's that do that?

[khasim]

I haven't seen any yet. Are you aware of any? I'd like to test them and see how well they work.

Re:Any examples of .rpm's that do that?

[vidarh]

A couple were already given you elsewhere. Here's a larger list: sendmail, exim, postfix all provide "smtpdaemon". httpd (Apache) provides "webserver". Firefox, Mozilla, Lynx all provide "webclient". coreutils provides the virtual packages fileutils, sh-utils, textutils, and "/bin/ls" for instance is part of "fileutils". Most applications that wants /bin/ls will either depend on /bin/ls directly or on the virtual package "fileutils" (again Sendmail is an example - it depends on fileutils, regardless of which package provides fileutils).

Not "knows better", but different approaches.

[khasim]

Every distro thinks it knows best.

Rather each distribution was started because someone looked at the other distributions and didn't find one that s/he liked 100% so s/he started his/her own.

This isn't about who "knows best" but which approach works for different people.

Why do we have Red Hat and SuSE and Mandrake when they're all Linux and they're all RPM-based?

Why are each of those slightly different from the other two?

The simple answer is because different people are using different approaches to do different jobs. So we see different distributions.

An example of a package that does that.

[khasim]

Great. So you claim that it works just like in Debian. So give me an example of a package in Red Hat or SuSE or whatever that does that.

Don't just claim that some functionality exists.

If you can't find any .rpm's that have that functionality, then why can't you?

Re:An example of a package that does that.

[vidarh]

I "claim that some functionality exists" because it is well documented, and it's existence easily verifiable.

As for examples, try Sendmail. Do an "rpm -q --provides sendmail" on a Fedora Core box, for instance, and you'll get "smtpdaemon" listed. Exim and Postfix for Fedora Core also provides "smtpdaemon".

It is not much used because there are very few cases where it is reasonable to use it - most applications that require something require a specific library or a specific application to be present, very few requires a capability that is met by many applications.

LSB says the directory structure should be...

[Anonymous Coward]

LSB suggests the directory structure should be more or less like the directory structure of what most Linux distros have now.
All /usr, /bin, etc.
They think everybody knows English or what /etc stands for.

Re:LSB says the directory structure should be...

[temojen]

They think everybody knows English or what /etc stands for.

Actually they think everybody knows UNIX. It wouldn't help someone who doesn't know english if the directory was named "/configuration_files" or "/configuration_du_ordinateur" or something similar.

On my system

[roystgnr]

$rpm -q --provides httpd | grep web
webserver

I understand skepticism, but you're a bit over the top. There's no Red Hat junta out to trick Slashdot into thinking that RPM has more features than it does.

FHS

[martguy]

Please could someone now focus on the Filesystem Hierarchy Standard? It would be nice to know where things are supposed to be stored. ( /opt or /bin ... I don't care, just decide on one location and stick with it!)

Thanks.

[khasim]

I understand skepticism, but you're a bit over the top. There's no Red Hat junta out to trick Slashdot into thinking that RPM has more features than it does.

Nope, but there are lots of people who make unsubstantiated claims.

I'll try building a .rpm tonight that depends upon "webserver" and see if that works. All I have at work are Debian machines.

Has the C++ ABI been fixed yet?

[iabervon]

Last I heard, LSB was requiring a version of gcc's C++ ABI that the gcc people said was broken and was being replaced. Due the scheduling desires, LSB 2.0 (IIRC) was released with the broken one, because a stable version of gcc which supported the new one wasn't ready yet. Did this ever get cleared up, or is it still broken?

The problem with getting ISO involves now is that not everything is completely correct at this point. Of course, it's not like people generally exactly follow ISO standards, either, so it may be just as well.

Re:Has the C++ ABI been fixed yet?

[JoeBuck]

No, the issue has not been fixed. LSB 2.0 specifies a document, and then specifies a library that does not match the document (requiring that everyone be bug-compatible with gcc 3.3). gcc 3.4.x is much closer to implementing the ABI standard correctly, but the LSB specifies 3.3.

The IEEE, ISO, or whoever should not bless LSB 2.0, at least the C++ part. A newer rev of the LSB should be produced that fixes the issue.

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.

*sigh*

[Anonymous Coward]

There is nothing wrong with the format.

What is broken is RedHat's v4 implementation which was written to be threaded by people who don't understand threading.

Re:*sigh*

[metamatic]

So, is there a non-broken implementation of the RPM tool? If not, what's the point of your quibble?

ISO standard = more expensive distro

[Anonymous Coward]

Not only it cost money to certify the kernel, but when the final standard is out, ISO has the audacity to charge people money for an already open standard freely available to community! Why should anyone support an outdated standardization committee model anyway, especially when hosting web mirrors are much cheaper than buying paper with contents already available with no cost?

No, no it doesn't.

[xant]

n.b. I'm actually running Ubuntu as you'll see, but it's the same package from Debian unstable.

$ apt-cache show lsb
Package: lsb
Priority: extra
Section: misc
Installed-Size: 188
Maintainer: Chris Lawrence
Architecture: all
Version: 1.3-9ubuntu7
Depends: lsb-base, lsb-release, xlibmesa3-gl | libgl1, xlibs, libz1, exim4 | mai
l-transport-agent, at, bc, binutils, bsdmainutils, cpio, cron, file, libc6-dev |
libc-dev, locales, lpr, m4, make, man-db, mawk | gawk, ncurses-term, passwd, pa
tch, pax, procps, psmisc, rsync, alien (>= 8.36), python (>> 2.2.2), debconf (>=
0.5) | debconf-2.0
Conflicts: python (>> 2.5), libutahglx1
Filename: pool/main/l/lsb/lsb_1.3-9ubuntu7_all.deb
Size: 25710
MD5sum: 8ab139caa1adac40a9a9d1ca1a27b629
Description: Linux Standard Base 1.3 core support package
The Linux Standard Base (http://www.linuxbase.org/) is a standard
core system that third-party applications written for Linux can
depend upon.
.
This package provides an implementation of version 1.3 of the Linux
Standard Base for Debian on the Intel x86, Intel ia64 (Itanium), IBM
S390, and PowerPC 32-bit architectures with the Linux kernel. Future
revisions of the specification and this package may support the LSB
on additional architectures and kernels.
.
The intent of this package is to provide a best current practice way
of installing and running LSB packages on Debian GNU/Linux. Its
presence does not imply that we believe that Debian fully complies
with the Linux Standard Base, and should not be construed as a
statement that Debian is LSB-compliant.
Bugs: mailto:ubuntu-users@lists.ubuntu.com
Origin: Ubuntu
Task: ubuntu-desktop

Re:No, no it doesn't.

[cortana]

Ah, so it's informative, not normative--fair enough. I never looked into it that deeply.

It's worth noting that the current version of the lsb package in testing/unstable is 2.0.

I wonder if all this is irrelevant anyway... vendors like Oracle say that their products will run on Red Hat version X and Suse version Y, rather than any LSB-Z compliant distribution.

Not to mention that Debian is about to break lsb compatibility in a fairly major way with Multiarch (http://raw.no/debian/amd64-multiarch-2).

Who does it serve?

[SkyLord]

Who does this really serve? Standards are nice, but the problem I could see is it might reduce the usage of "non-standard" distros. Not from a technology or licensing standpoint, but after a few generations, only the groups that follow the standard will be able to be "approved" or "supported".

While this may not seem like a problem in the short term, it seems to me that this only serves the commercial distros. ISO is an industry standard, but how does this serve the Linux product as a whole, other than to caste the community?

Is Linux as a community "forking" off "real" distros, from the "rabble"?

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.

I don't agree with that.

[khasim]

It is not much used because there are very few cases where it is reasonable to use it - most applications that require something require a specific library or a specific application to be present, very few requires a capability that is met by many applications.

Yet it is used a LOT on Debian.

I'm not talking about libraries.

I'm talking about things like:
text editor
webserver
smtp
etc.

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.

Such as with Debian.

Otherwise I end up with 10 different text editors because 10 different people packaged 10 different apps that required a different text editor each.

The more applications I have installed, the longer it takes to maintain my systems and the more avenues there are for a cracker to attack it.

Part of Security is getting rid of things you don't absolutely need.

With Debian, I can have ONE text editor and if there is some terrible flaw found with that one, I can remove it and switch to a different one.

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?

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:GNU?

[SkyLord]

People who do not understand the technology need standardization. it's not the users/admins/engineers of Linux/GNU/OSS/whatever that need the standards, it's the managers/salespeople/directors/vendors/beancounter s that need to to feel more comfortable with adopting something. It's easier to sell something that is "supported" that gives a director someone to "blame". If gives perimeter groups better feelings that they are following a "standard" or a "platform". Vendors can support a known configuration.

The sole reason for this is money. The creation of money and an entirely new business model and a large number of companies that would like to keep the money they have made and make more of it. The only way to do that is to provide stablility to the platform. Less answers to customers asking why this or that won't work with their version. Less problems. More ability to blame someone else "it doesn't work because the distro you are using is non-standard!".

It's all about the $$$ :)

Sucky legacy platforms???

[JFMulder]

on sucky legacy platforms, etc. etc
Neverminding the fact that Linux is an open implementation of a 30 years old architecture.

Re:Sucky legacy platforms???

[SkyLord]

That's like saying a custom hod rod built from scratch is an open implementation of a 140 year old architecture. (the first Internal Combustion Engine was built around 1864).

Why the heck are we still riding around in these claptraps! Where are all the flying cars?

Re:Sucky legacy platforms???

[JFMulder]

The difference is that the limitations in how you put the engine inside the car are not the same as before, while people are still using in good part the same old APIs in Linux.

Re:Sucky legacy platforms???

[SkyLord]

This could be dialed down to very specific levels to validate or invalidate either argument. I'm not a kernel hacker at all, but if you read some of the histories of OS's, the main NT architect worked on VMS, and much of the early foundations on NT/2k/XP are based in much older OS's.

We could churn on things like that forever. I don't usually hold alot of stake on how old something is or getting rid of something or keeping something based upon age (either way).

Does it work? How much will it cost? Can it be supported?

Heck...You still have companies buying mainframes...and with the way that OS's are becoming more abstract, with abilities to put a whatever OS on whatever hardware, then the real question is does it do what you need?

If it does, good, if it doesn't, get something that does. :)

WordUsageError

[premchai21]

Risk averse, not "adverse".

IBM and Gentoo

[sp0rk173]

Interestinly enough, while IBM might be officially backing SuSE and Redhat (which I'm not sure of, I haven't looked into that much) they unofficially have poured quite a bit of resources into the Gentoo project. You might want to check that out, kid.

back to package format versus manager.

[gimpboy]

I suppose it should be mentioned for clarity that the issue you have is a problem with the package _manager_ and not the package _format_. The format is all the lsb covers.

No To ISO

[Anonymous Coward]

ISO is not made of hackers. It is made of suits. Suits are idiots who try to push DRM and other stupid technology on us. JUST SAY NO.

Read it again.

[khasim]

As I've pointed out before, and as others have pointed out, this has nothing to do with the package format. RPM supports it.

Yes, the other poster confirmed that. I'm going to test it out tonight, at home, to see if there are other issues with it. But at this moment, this is no longer about whether or not you can put a "provides" in a .rpm package. You can.

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'm not doing that. YOU are the one claiming that such functionality is seldom needed.

I've pointed out that Debian uses this a lot.

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?

Well, to use your examples "Sendmail, Exim, Postfix". Here's a good start http://packages.debian.org/testing/virtual/mail-tr ansport-agent

http://packages.debian.org/testing/virtual/radius- server

http://packages.debian.org/testing/virtual/httpd

http://packages.debian.org/testing/virtual/editor

http://packages.debian.org/testing/virtual/mail-re ader

There, that should be enough examples. Common tasks, handled by a multitude of apps, each available as an option under a specific "provides".

All nicely labeled and set out so they can be easily identified and referenced.

The i-triple-what ???

[frost22]

ISO standardization is all nice and good ... but can a reasonable person please explain to me why this stuff would be also submitted to a US domestical eletcrical engineer's professional organization (the Instute of Electrical and Electronical Engineers inc.) ? Since when is the ieee more relevant than the professional organizations in some hundred other countries ?

And, while we are at that, is that true at all ? I don't see any mention of ieee in the referenced article

Re:The i-triple-what ???

[Maljin Jolt]

Since when is the ieee more relevant than the professional organizations in some hundred other countries ?

In past sixty years of computer technology, it happened many technology standards were IEEE well decades before ISO. ASCII code and interfaces such as RS-232 or RS-488 are examples of such IEEE nomenclature.

Re:The i-triple-what ???

[uncommonlygood]

You're right, this apparently has nothing to do with the IEEE. It isn't even associated with ISO as far as I can tell (the american representative is ANSI)

That said, the confusion may arise from the fact that the IEEE already standardised some parts of UNIX through the POSIX set of standards. These were, I believe, originally intended to make commercial UNIXes play a bit nicer, but the Linux kernel and GNU tools mostly aim to comply with POSIX as well for the sake of standardisation.

Also, I'm not an American, so don't just think I'm being an arrogant yank, but IEEE standards are used throughout the world - many other standards (like firewire, one of the versions of ethernet, wi-fi lans (802.11 stuff) and many other networking bits and bobs) are standardised by IEEE committees, so in many ways they are more influential that professional organisations in other countries. Also, membership of the IEEE is not exclusive to US citizens. I'm not sure exactly how many countries they allow members from, but certainly most UK EE/CS degrees will get you in.

A nice big list of examples

[Dwonis]

Why don't you provide some examples?

Virtual packages are used extensively in Debian. I've generated a list of Debian virtual packages from the packages available via apt-cache dumpavail to demonstrate this.

The list was constructed by taking the set of all packages that are Provided by other packages, and removing the set of all real packages and the set of packages that are Replaced by other packages. (This is more accurate than aptitude's algorithm, which apparently doesn't account for Replaced packages.)

Here is the result - 608 virtual packages (note that a few of them, such as mplayer, are from third-party package sources):

[Sigh. I've also crammed them all onto one line, since Slashdot complained that my "comment has too few characters per line (currently 14.2)".]

alias alsa alsadriver alsalib-dev alsaplayer-interface alsaplayer-output amarok-engine apache2-dev apache2-modules aptitude-doc asd aspell-dictionary audio-mixer autoinstall-arch automaken awk babel bacula-director beecrypt-dev blas2 blas2-dev bnlib-dev bochs-gui c++-compiler c-compiler c-compiler-avr c-compiler-m68hc11 c-sharp-compiler c-shell cfengine-skolelinux cheetah chill-compiler cl-imho-web-connector cl-sql-backend cl-uncommonsql-backend clanlib0-display clanlib0-input cli-common cli-runtime cli-virtual-machine conch console-utilities cracklib-dev ctags cyphesis-cpp-game debconf-2.0 dict-client dict-server diskless-image docbk-xml doom-engine doom-wad doom-wad-editor dotfile-module dtp-i2o-raidutils dyndns-client ecpg editor elf-binutils elf-libgdbm emacsen endeavour enlightenment-theme entity-perl epic4-script epos-sound-data exim4-config-2 ext2fs-dev ezpublish festival-voice fftw-double-dev fftw-single-dev fftw2-double fftw2-single finger-server firebird2-server flask flite-dev fortran-compiler fortran77-compiler fortran95-compiler fortune-cookie-db freeciv-client freecraft-data freeglut-dev freetds freetype2-dev fsck-backend fwbuilder-backend fwbuilder-frontend gap-pkg-ctbllib gap-pkg-matrixss gap-pkg-tomlib gap-prim gap-small gap-trans gcc-docs gcompris-sound gdk-imlib gdk-imlib-development gforge-db gforge-dns gforge-ftp gforge-ldap gforge-lists gforge-mta gforge-shell gforge-web ggz-core-client ggz-graphical-client ghc-hopengl ghc-prof giflib-dev gift-client gift-plugin gimp2.0 glibc-2.3.2.ds1-20 gmt-coastline-data gnue-forms gnustep-base-dev gnustep-gui-dbg gnustep-gui-dev gnustep-xgps gopher-client gopher-server gstreamer-audiosink gstreamer-videosink gstreamer0.8-audiosink gstreamer0.8-colorspace gstreamer0.8-videosink gtk+2.0-directfb0-udeb gtkgl-dev gtkglarea-dev guile gvim haskell-compiler hostap-modules httpd httpd-cgi i18ndata i2c-mod-2.9 i386 ifupdown-scripts ike-server imap-client imaze imho imlib imlib-development inetd info-browser iraf-common irc ispell-dictionary itcl-dev itcl-doc itclsh itk-dev itk-doc itkwish iwidgets-doc j2re1.3 j2re1.5 j2sdk1.3 j2sdk1.5 jabberd2 java-compiler java-virtual-machine java1-runtime kakasi-dev kde-i18n kernel-doc-2.2 kernel-doc-2.4 kernel-doc-2.6 kernel-headers kernel-image kernel-source kernel-tree-2.4.24-1 kernel-tree-2.4.25-1 kernel-tree-2.4.26-1 kernel-tree-2.4.27-1 kernel-tree-2.6.10-1 kernel-tree-2.6.8-1 kernel-tree-2.6.9-1 killustrator koffice-i18n konversation-doc kwave-doc kworldwatch ladspa-host ladspa-plugin lambdamoo-core lambdamoo-server langband-variant lapack2 lapack2-dev ldap-client ldap-server lg-issue libacme-brainfuck-perl libadasockets-dev liballegro3.9.37-dev libannodex-dev libapache-mod-roaming libapr-dev libapt-inst-libc6.3-5-1.0 libapt-pkg-libc6.3-5-3.3 libardour-dev libarpack libaspell11 libasprintf-dev libasprintf0 libastro-fits-header-cfitsio libatlas-3.so libatlas.so.3 libatm-dev libawe-dev libblas-3.so libblas.so.3 libbluetooth-dev libc-dbg libc-dev libc-pic libcairo-dev libcgi-kwiki-perl libcgicc-dev libchipcard-dev libchipcard-pcsc-card-perl libclamav libclamav-dev libcmml-dev libcomerr-kth-compat libcupsimage-dev libcupsys-dev libdancer-xml-dev libdb++-dev libdb-dev libdb-java li

No One Noticed This ???

[c_spencer100]

One of my fellow Slashdot readers posted this link. The LSB faq says many distros, including a few non-RPM based ones, agreed on RPM being the standard package format. Debian, Storm, and Corel Linux were the distros named. Not only are they all Debian based, but Storm and Corel have been discontiuned for a while now

Even more interesting is the future packaging plans of the lsb. The faq states intent to implement a deb/rpm packaging format. Now this is good for Debian (probally the sole reason they agreed to rpm), but where does that leave other non-rpm based distros? Slackware is my distro de jour, yet I havene't read any plans, or heard of any consideration in the slightest for the first (and possibly the fastest) distrobution of Linux.