Why RPM is better than DEB for MeeGo?

Question

I know there has been a lot fuzz about this subject on various forums and newsgroups concerning the merge of Moblin and Maemo. I'd like to know what stackoverflow-fellows think about this. What are the benefits of RPM packaging over DEB that make it better choice for MeeGo?

Novotny

Answer 1

RPM is specified as the packaging format for the Linux Standard Base.

...

Okay, I admit it, that's stretching for an answer, even for me. There isn't an awful lot of difference in the base purpose of both RPM and DEB packages; they each have their own distinct capabilities, but in the end they're both a bag of files and metadata.

Wilk

debs run on at least 8 chip architectures. rpm doesn't support that many. debs have superior sat solving compared to rpm. Other tools have caught up, like zypper, but debs were a real innovation that allowed one to escape "dependency hell." debs work so well that Debian is considered "the most important Linux distro", for whatever that is worth. But using apt to install a deb is dead easy which is probably why so many distros base on Debian. I think all those things demonstrate a huge difference between the two formats. – Inkerman

@jeremiah: x86, x86-64, IA64, S390, PowerPC, SPARC, Alpha, MIPS, SH3, ARM... and I think I missed a few. If you're going to talk about "rpm the tool" then at least have the integrity to compare it to "dpkg the tool". – Wilk

Umm, sure. I don't mean to denigrate the "tool" but the thing is rpm needs to be able to run on your platform if you aim to be Linux Standards Base compliant. So the irony is that it is likely that Debian packagers ported rpm to those platforms to keep their official support for LSB rather than any inherent architectural decisions internally in rpm. – Inkerman

The LSB restricts RPMs so that they may only depend on other LSB modules, so most RPM modules are not LSB compliant. APT's Alien package allows LSB packages to be built directly; they are the APT packages beginning lsb-. See wiki.linuxfoundation.org/en/Book/Packaging – Allethrin

Answer 2

There are a couple important differences between these two package formats and they go beyond mere technical distinctions.

Firstly, APT (the Advanced Packaging System), which creates and uses debs, is a complete packaging system that traditionally has had better support for dependency tracking. This is important because when you install a package, you often have to install a bunch of other packages that your package relies on. If you don't, often your package will not run. This type of dependency resolution is one of the strengths of the deb packaging format. rpm has poor support for this and as a consequence other tools (yum, zypper) have grown up to try and replicate the sophisticated dependency resolving that APT does.

Secondly, Debian is a sort of "reference" platform. It calls itself "the universal operating system" mostly facetiously but there is some truth to it. Debian's social contract and support of Free Software means that it is not controlled by a single entity or corporation. This means that the implementation is open for constant improvement and it is easier to integrate software. The consequence is you have an OS that runs on 8 chip architectures officially and some others unofficially, so a deb package will install on a lot of different types of hardware that rpm will not even run on. With Debian being the reference platform for things like the perl programming language and R statistical programming language, it means that your deb will likely be able to have the dependencies it needs to be easily integrated into your system. Debian also has a lot of subject matter experts who are drawn to it because they are able to work according to their interests and abilities and are not forced to consider profit and loss statements.

This means that a deb is often not just superior technically because of its package specification, but also because of the ecosystem of developers it plugs into.

Inkerman

Answer 3

I know nothing of Moblin and Maemo, but I have done a lot of software packaging. I would favour the choice of rpm over deb as the file format I would pick for any operating system where I could chose. Before apt existed for rpm, I greatly favoured debian over redhat derived systems. yum is nearly as good as apt. As I learnt both packaging systems I would rather deliver rpm than deb.

A comparison of rpm and deb:

(1) For Binary Data, rpm uses cpio, deb uses ar. cpio is the more cross platform choice being chosen as the default POSIX archiver. ar is the traditional archiver.

(2) For Source Data, srpm (a special type of rpm) uses cpio with a single special file that automates the process of building an rpm, and is generated when any rpm, is built correctly from source. deb on the other hand uses a multitude of compression systems as the original source vendors input format is supported, optionally also a series of patch files, and 3 magic files each with a different file format.

(3) Making functional rpm packages is considerably easier in my experience than making deb files.

(4) Making a functional chroot in rpm based systems is standard rpm commands, while in deb based systems it is a specialised script called debootstrap.

Only apt from the debian camp, seems more usable than yum from the redhat camp, all the upstream QA tools seem better from the Redhat Camp.

I suggest that Making an rpm is not a magic art, just some thing you have to train people in.

A comparison of rpm and deb QA tools:

(1) Repository builders: createrepo is the tool, simple to use and understand. mini-dinstall, dpkg-scanpackages or dak (Debian Archive Kit) or mini-dak or reprepro or debarchiver or debpool or DebMarshal or apt-ftparchive or dpkg-scansources are either complex or poorly documented, or missing a critical feature, and some times all three.

(2) "Source deb" are not a single file like srpm is a single file, and so require special tools to move them around.

(3) Build servers: Koji beats pbuilder every day of the week in documentation. It must be said though that pbuilder is quiet cool.

I am amazed no clear best tool for making a deb based repo exists. The ones I have tried are poor. None I have tried are nearly as good as createrepo is for rpm. (reprepro is nearly as good as createrepo from rpm except it wont allow multiple versions of the same package in a single repository, so ruling it out for most continuous deployment systems.

Conclusion : A comparison of rpm and deb

I think picking an rpm tool chain is better on their part. Just as the interesting link by Charles Stewart stated its the tools that matter.

Hanover

Answer 4

Decision to give up DEB for RPM for Meego and other similar ones had been purely political & business. Technical opinions had been ignored. Your question (as question) is valid in general context but in Meego case it appears as attempt to justify already-done-step afterwards. Nevertheless, we will never know technical merits pro and contra - Meego is now gone different way, where deb-vs-rpm competition is excluded.

Squinch

Answer 5

At this point, I guess this should probably be a Linux & Unix question.

It's not really true to say that Meego switched from APT (i.e., .deb) to RPM; instead, Meego was a merger of the APT-using Maemo with the RPM-using Moblin. Robin Burchill said on his blog last February - http://blog.rburchell.com/2010/02/meego-rpm-vs-deb-debate.html - that it was easier to go with RPM because Moblin dictated more of the architectural choices within Meego, and refactoring Maemo was easier.

Allethrin