This week at LWN: Who maintains RPM? (2011 edition)

@skelband, I don't mean RPM and DEB in general, I'm responding to the fact that he doesn't like that there are more than 2 package managers.

>How much packagers of all the big software projects must grind their teeth when they have to, not only package for DEB and RPM, but also for the variations in the main distributions as well.

I know the Ubuntu DEB are a bit different from the Debian DEB's, but as far as I know, I have never had a problem installing a Debian DEB on my computer. As for RPM, I don't know. If I release software, I would make it available in DEB, RPM, and packed in .tar.gz (like most do). This isn't so hard to do, and is totally not a deal breaker for me.

The main problem I think for most developers is the difference in the distro itself, not the packaging.

Quoting:I know the Ubuntu DEB are a bit different from the Debian DEB's, but as far as I know, I have never had a problem installing a Debian DEB on my computer.

Then you were lucky. It could have blown up in your face and we would have just stood there and laughed. Binary packages are distro specific.

As for the deb/rpm schism, it doesn't matter. End users never see the difference because package manager frontends like Synaptic work everywhere and hide the details. Geeks often have strong opinions and good technical reasons not to switch format

Ok, thanks for the info Sander! I didn't know that.

Quoting:As for the deb/rpm schism, it doesn't matter. End users never see the difference because package manager frontends like Synaptic work everywhere and hide the details. Geeks often have strong opinions and good technical reasons not to switch format

I agree with that.

I was running Foresight Linux for a bit. It uses conary. And I have to say, I really like it. It's kind-of like having all your software managed via subversion or something similar. Overall it just seems like a better way to have a rolling distribution.

I'll revisit it again in a few months to see if the community has grown, more software becomes available, etc.

jacog,

It's early, so this is how I read it:

Quoting:I was running Foresight Linux for a bit. It uses co[r]nary. And I have to say, [...]

It's really heart stopping ...

YBT

Saaay YBT - are you taking shill-checks from the Heart Foundation now too? My God, man... how low will you stoop?

jacog,

If the cash is on the floor, I stoop to conquer my greed. Non-profit is for the agency and taxation purposes. Not for me.

As always,

YBT

I think that my main point about the divisive nature of the two managers was that if only an RPM was available and you had a DEB based system, then you are pretty much stuffed unless you go down the Alien route which most end-users are not going to do.

It would be cool for a distribution to support both by some amalgamated package management technology. It could be done and would be useful for the end user.

I know that techies argue the toss over which is better like we argue about vi and EMACS. I see the need for evolutionary development along multiple paths which gives us the best of breed type of end-result, but I don't see who benefits from two end-results though on such a core technology. Again, I cite the ODF example. We had a number of different doc formats emerge over the years, but everyone sees the benefit of a single portable format that everyone can support for interoperability. You may have differing opinions on which word processor you prefer but in the end you need a common format to allow you to move from one to another.

I don't see that either the DEB or RPM format is going to evolve much further from this point on. So I therefore don't see the continuing need for two separate systems of package delivery. Whether or not it is actually possible to bring to two camps together at this point is another thing entirely though :D

Also worth considering that other formats might be better than both DEB and RPM.

Quoting: [;,,] My God, man... how low will you stoop?

For clarity, "A Shills Anthem"

If it is buried I will Digg for it.

Moreover, I will slash your dot for views.

And patent rights are not to be sniffed at.

Furthermore, I am Mono maniacal in getting into your stack.

Where misleading the ill informed, those easily herded and directing the confused,

is my stock && trade while making me bemused.

However, only for the gift of a significant portion of the Cash horde.

So when I am asked, how low will you go?

I say Bling it on.

YBT

Txt,

In keeping with your honorable position as resident shill, shouldn't that last sentence read:

"I say Bing it on"?

G

Sir Dr. G.,

Very unfortunately, you are correct. I always have read it as bling, like the counter rotating hubs on cars that puts the susceptible into terminal epileptic shock.

Now if MS had only listened to me, it would be leading the search with Bling not this damn bing or ping or sing Crosby Crap.

I will not recant, MS is wrong and they would have owned the market had they a more discerning management. There is only so much a first class shill can do.

Sadly,

YBT

> There is only so much a first class shill can do.

It's OK, Txt. Anyone here will be happy to testify that you've always done your best.

jd,

Your words bring me no comfort, because I am an abject failure as a shill.

Your Sad Buddy Txt.

P.S. Bling is soooo much better than Bing ... what were they thinking?

@skelband; *Why* would you care about the package source format? Think about it, it really makes littel sense at all. End users don't see it. They only see the compiled, binary packages and they are non-portable anyway (yes, really! Any portability is either accidental, or because the package in question contains every dependency it needs down to the base C libraries).

The only people who really care about this are maintainers of closed-source software. They can't be arsed to maintain source packages in two formats and then build umpteen binary packages from it. Open source software people can simply hand over their source code to the distro packagers. For my software, I have only ever build a few .deb packages in order to support old Ubuntu versions when I first released. Yet, you can find new DEB, RPM, TGZ and many other packaged formats of my software.

@Sander_Marechal: Well I actually don't really care that much :D

I don't maintain packages for any distribution although I have built DEB packages before so it doesn't affect me directly at all.

It just seems to me that there is so much duplicated effort. It worries me that DEB and RPM packages are not portable. They really should list all of their dependencies. I realise that names of dependent packages vary from distribution to distribution and that's an issue as well.

It just doesn't seem logical to me to have two systems purporting to achieve the same ends. Package distribution is so core to Linux distributions that I think of it in terms of components like HAL, SANE and Xorg rather than OpenOffice or GIMP.

Yes, we have KDE and GNOME etc but they are radically different and we see them evolving at a rapid pace. It makes sense for these things to go their own way since their evolution is contributing to the Linux ecosystem. I just don't see any evolution in package management and we are unlikely to see it in the foreseeable future.

If we continue with separate DEB and RPM it's not the end of the world. It is a shame that we cannot rid ourselves of some unnecessary cruft in the Linux environment by agreeing on something that everyone will use. We might even see a new package management system appear in the future. If it takes over from DEB and RPM with some great new ideas then great. I can't see it at the moment though. ;)

Quoting: The only people who really care about this are maintainers of closed-source software. They can't be arsed to maintain source packages in two formats and then build umpteen binary packages from it.

Actually, why can't they?

After all, Opera does, for just one fairly obvious and high-profile example.

Don't they have the source code? Don't they have ready (and generally "free" access to whatever build environments (aka "distros") they might be interested in.

And I'm not sure they even actually need the distro on hand (though it might be easiest). Besides, haven't I heard of "build services" that let software writers put in code and get out nice neat binaries properly compiled for whichever distros they've selected? So clearly it not only can be done -- it can be automated.

And even for Windows they already have to do this, anyhow, right? Even if they might hide this from clueless users with an installer that checks which version of Windows it is running on, and varies the install accordingly. And if (when?) it won't run properly anymore, after some Windows Update patch or Service Pack or whatever, won't it be a lot harder to track down the bug?

Of course, I'm not a software developer, so I may be totally clueless...

Quoting:Actually, why can't they?

Good point. That why I wrote "they can't be arsed" instead of "it's very hard" or "complicated" or "expensive" or some such apology.

That's a bit harsh though. Even Opera, who sprouts an impressive list of supported distros, doesn't support them all.

@BernardSwiss --

The biggest problem is not package formats. That borders on trivial... a couple of extra steps in the Makefile or some such.

Testing is less trivial, but, the nature of the testing required probably means it can be automated also.

The real problem is distributions, not package formats. The more the distributions differ, the more difficult it is to support them. The more they look alike -- at least from a standard libraries and utilities in standard locations standpoint -- the easier, especially if support amounts to little more than some assurance that things will install correctly and be usable.

Diversity is the stuff of greatness in Open Source,... So, have to disagree that too many distros are bad... Not having enough choices is WORSE...