Hi,
[Please pardon the cross posting. I felt that this mail is not off topic for any of the mailing lists I have posted it to, and it is about time we had a technical, as opposed to sentimental or loyalty based look at the .deb and .rpm file formats, I have read the acceptable use policies of all three lists, and I think this is not in violation of any of them. I apologize if I am mistaken]
It might be instructive to compare package file formats on a purely technical level: http://kitenet.net/~joey/pkg-comp/ This is a fairly authoritative document, and well worth understanding.
Here follows commentary on the major points of difference oj just the rpm and deb format (please read the URL for details regarding other package formats).
1) Data unpack-able by standard tools, meta-data accessible by standard tools, and ability to create a .deb with standard (non distribution specific) tools: .debs are just ar archives of tar-balls, and can be unpackaged, inspected, and created using cp, chmod, ar and tar. rpm's need a special tool. Now, why is this important at all? Well, think of a classified environment, where you do not want to rely on the packaged tool to help you with forensics; but you have a trusted solaris box.
2) Package relationships: The .deb format has a more nuanced set of relationships, incorporating recommendations and suggested packages, and orders packages by priority as well as group.
rpm does not have the nuanced relationship, nor priority, but it does have file based dependencies, and easily extract-able copyright information so it is easier to marshal packages by copyright info.
Personally, I am of the opinion that file dependencies are a mixed bag; they complicate the package dependency graph with edges that are different from a package dependency; added to the less nuanced dependency and priority information, they make the installation ordering of rpm's far less sophisticated.
dpkg goes through a song and dance ordering packages with topological sorting of the graph, breaking installation into chunks to ensure that no conflicting packages ever are unpacked at the same time, unpacking and configuring packages in dependency order, and rolling back failed installation. rpm does installations on a best effort basis, and thus failures at critical stages leave the system in an untenable state.
3) rpm can mark documentation files (makes it easier to find docs), and has ghost files, files which are not shipped in the package but are registered as being owned by the package. For documentation, Debian relies on convention; all package documentation is found in /usr/share/doc/$package; but ghost files are clearly a plus for rpms.
4) Debian packages may run binaries at install and un-install times. I am not sure if this is a major plus.
5) Package verification and triggers -- rpm has them, and package verification is one of the major features missing in a .deb. triggers, well, there is a technical proposal currently being debated about adding triggers to dpkg, but obviously, Debian is playing catch-up here.
6) New sections in the package format: .debs were designed to be extensible, and whole new sections can be added to the package by adding yet another tar-ball or the ar archive. Some of the future additions being planned are detached signatures by various keys; developers key, build daemon maintainer key, archive maintainers key, release manager key, mirror master key, -- in a new section of the package file. So, new data sections, compiled binaries for more than one sub-arch, or 32 and 64 bit binaries -- they can be added easily to a new section, and dpkg be told how to deal with the new sections by inspecting the .deb format version.
rpm's can't as easily cope with unseen new requirements.
manoj
Manoj Srivastava wrote:
Hi, Here follows commentary on the major points of difference oj just the rpm and deb format (please read the URL for details regarding other package formats).
Am not sure if this is included but also add that 'rpms' are non-interactive.. no interaction at all.. period. .debs on the other hand IIRC, can do some post/pre thing.
Though i come from a rpm background and the current state of affairs is not too encouraging, addition of apt/yum has done wonders to rpm and takes care of the dependency hell (yes it did exist). Also redhat, novell and others have recently come together again to maintain RPM and take it forward from the current state.
A nice read anyways.. just to support RPM, yum adds recommendations and suggestions to RPM. Also 'binary programs allowed' sounds confusing as RPM does support packaging of binary files. Another plus of an RPM is the '-V' option to verify the integrity of an installed RPM (i am not sure if that exists in deb)
- dhawal
On Wed, 28 Feb 2007 22:19:44 +0530, Dhawal Doshy said:
Am not sure if this is included but also add that 'rpms' are non-interactive.. no interaction at all.. period. .debs on the other hand IIRC, can do some post/pre thing.
Not having used rpm's recently, I was not sure if there is a debconf equivalent. debconf can have a GUI, curses, or readline front-end, and the interaction is internationalized, so the questions can be asked in the native tongue of the person doing the install, if the translation is up to date.
Though i come from a rpm background and the current state of affairs is not too encouraging, addition of apt/yum has done wonders to rpm and takes care of the dependency hell (yes it did exist). Also redhat, novell and others have recently come together again to maintain RPM and take it forward from the current state.
A nice read anyways.. just to support RPM, yum adds recommendations and suggestions to RPM. Also 'binary programs allowed' sounds confusing as RPM does support packaging of binary files. Another plus of an RPM is the '-V' option to verify the integrity of an installed RPM (i am not sure if that exists in deb)
Well, this is meant to be talking about the stuff run pre/post installing a package. for rpm, it has to be in the spec file -- which means that it must be a script. For debian, since they are in external files, you could sneak in a compiled binary (which would be against policy, but hey, you could do it)
manoj
Manoj Srivastava wrote:
On Wed, 28 Feb 2007 22:19:44 +0530, Dhawal Doshy said:
A nice read anyways.. just to support RPM, yum adds recommendations and suggestions to RPM. Also 'binary programs allowed' sounds confusing as RPM does support packaging of binary files. Another plus of an RPM is the '-V' option to verify the integrity of an installed RPM (i am not sure if that exists in deb)
Well, this is meant to be talking about the stuff runpre/post installing a package. for rpm, it has to be in the spec file -- which means that it must be a script. For debian, since they are in external files, you could sneak in a compiled binary (which would be against policy, but hey, you could do it)
much clear.. thanks.
Dhawal Doshy wrote:
Manoj Srivastava wrote:
Hi, Here follows commentary on the major points of difference oj just the rpm and deb format (please read the URL for details regarding other package formats).
Another plus of an RPM is the '-V' option to verify the integrity of an installed RPM (i am not sure if that exists in deb)
Well the TFA says it does.. .deb does provide checksums for all the files in the package.
Also forgot to add, one major drawback of RPM is the db3/4 based backend in /var/lib/rpm which is highly fragile and needs some serious re-design..
Dhawal Doshy wrote:
Dhawal Doshy wrote:
Manoj Srivastava wrote:
Hi, Here follows commentary on the major points of difference oj just the rpm and deb format (please read the URL for details regarding other package formats).
Another plus of an RPM is the '-V' option to verify the integrity of an installed RPM (i am not sure if that exists in deb)
Well the TFA says it does.. .deb does provide checksums for all the files in the package.
Also forgot to add, one major drawback of RPM is the db3/4 based backend in /var/lib/rpm which is highly fragile and needs some serious re-design..
To add some more.. a major feature for RPM (the SuSE version) is 'delta-rpm', which lets you download only incremental changes for an already installed RPM. The incremental changes are then used to recreate a newer RPM. Does something like this exist for .debs?
In any case, with the upcoming collaboration of redhat, novell, mandriva etc.. i'd prefer rpm over any other packaging format for purely comfort reasons (which also includes laziness). And as far as managing packages is concerned there are various options available 'rpm itself', up2date, yum, apt, smart etc.. currently i prefer yum but that could change if required. Apart from dpkg, apt (and maybe synaptic) i am not aware of .deb package management tools.. apt is already good and some features from yum like 'use closest mirror' etc if ported to apt would make it really cool.
Finally i love the way redhat and clones package their systems using anaconda, kickstart etc which makes installation a breeze for newbies and experts alike. I'd also like show-off my new-found love for cobbler (cobbler.et.redhat.com) but that'd be OT.
To conclude, packaging doesn't matter for most users (especially the desktop users). It mostly matters to Administrator who either run large sites and require tonnes of automation OR need a lot of custom software packaged in their own manner. I'd mostly continue to be a rhel user .rpm or not.
- dhawal
On Thu, 01 Mar 2007 15:27:02 +0530, Dhawal Doshy said:
To add some more.. a major feature for RPM (the SuSE version) is delta-rpm', which lets you download only incremental changes for an already installed RPM. The incremental changes are then used to recreate a newer RPM. Does something like this exist for .debs?
There has been some talk about rsyc friendly .debs, but I am not aware of the state of that effort.
In any case, with the upcoming collaboration of redhat, novell, mandriva etc.. i'd prefer rpm over any other packaging format for purely comfort reasons (which also includes laziness).
And the rest of your post descends into matter of preference, as opposed to the technical comparison I have been doing, and is likely to lead into violent opposing expressions of personal preferences of other people on the list.
I am not interested in who like what; the underlying concrete reasons for basing such decisions are far more important. I care abotu having information to make my decisions, and sharing the concrete data, finished products of such decisions and cogitation are less useful for other people; and perhaps you could start a different thread about preferences?
I'm still looking for actual differences between the package formats, or build systems. I steer clear of the front end comparisons as well, since it is harder to separate the subjective from the objective there.
manoj
Manoj Srivastava wrote:
On Thu, 01 Mar 2007 15:27:02 +0530, Dhawal Doshy said:
In any case, with the upcoming collaboration of redhat, novell, mandriva etc.. i'd prefer rpm over any other packaging format for purely comfort reasons (which also includes laziness).
And the rest of your post descends into matter of preference,as opposed to the technical comparison I have been doing, and is likely to lead into violent opposing expressions of personal preferences of other people on the list.
pronounced guilty.. i accept drifting to OT.. Just to summarize and add some more:
a. RPMs are non-interactive: there are pros and cons for this.. b. The RPM backend database is *very* fragile and the recovery procedure is not too easy c. RPM can be extracted using non-proprietary tools, see: http://fedora.redhat.com/docs/drafts/rpm-guide-en/ch-extra-packaging-tools.h... d. RPMs support deltas (which makes downloading updates much lighter on bandwidth) e. RPMs packages can be signed using sha1 in addition to md5, pgp/gpg f. A source RPM (OR tgz/bzip2.gz + SPEC file) can be used to build multi-arch packages on a single arch (if you have the development tools available). For instance: i do not need a x86_64 machine to build x86_64 specific RPMs and can do it on a i386 machine. g. RPM supports advanced package queries: for instance 'rpm -q --changelog installed_rpm' will actually show the changelog for the spec file. h. RPM supports rudimentary database management utilities, which is not necessarily a good thing always. Further management requires knowledge of berkeley db. i. RPMs can be relocated during installation.. so i could ask rpm to install the httpd rpm in /usr/local/ j. RPMs can be made extensible (though not infinitely) by using macros in reference to the 'new section' part of the URL you posted k. No repository integration with RPM and hence the lack of recommendations and suggestions, but wrapper/front-end tools like yum/apt can overcome this.
That is all i can add at this point..
- dhawal
On 28/02/07 10:05 -0600, Manoj Srivastava wrote: <snip>
chmod, ar and tar. rpm's need a special tool. Now, why is this important at all? Well, think of a classified environment, where you do not want to rely on the packaged tool to help you with forensics; but you have a trusted solaris box.
A unix system without cpio? RPM is essentially cpio with a specified header format. <snip points 2 and 3>
- Debian packages may run binaries at install and un-install times. I am not sure if this is a major plus.
RPMS can run binaries from pre and post install sections. This is not a major plus, and in some environments can be a major minus.
Devdas Bhagat
On Wed, 28 Feb 2007 23:33:51 +0530, Devdas Bhagat devdas-B/gC27/pXbteH41UXmfQsti2O/JbrIOy@public.gmane.org said:
On 28/02/07 10:05 -0600, Manoj Srivastava wrote:
snip>
chmod, ar and tar. rpm's need a special tool. Now, why is this important at all? Well, think of a classified environment, where you do not want to rely on the packaged tool to help you with forensics; but you have a trusted solaris box.
A unix system without cpio? RPM is essentially cpio with a specified header format.
Actually, no: it is a modified cpio. The implementation is pretty close, but it has some behaviors which are more to RPM's liking. If you take a plain old cpio from Solaris/Aix/HPUX et al you'll find that you can't really inspect/create rpm files.
Which is why we have rpm2cpio package, it converts the rpm to standard cpio format. If it was a plain old cpio, you would not need rpm2cpio.
- Debian packages may run binaries at install and un-install times. I am not sure if this is a major plus.
RPMS can run binaries from pre and post install sections. This is not a major plus, and in some environments can be a major minus.
Well, not if you wanted to do a preinst, and the binary you want to run is inside the package. See, the package has not been unpacked yet, just hte spec file is available -- or the debian maintainer scripts.
So, debian's preinst can be a binary program, as well as a postrm -- but the rpm spec file can't do that, since the binary it could refer to would not be available.
It is not a major issue, and Debian specifically prohibits it in policy; but it is a technical difference.
manoj
Quoting Manoj Srivastava srivasta@debian.org:
On Wed, 28 Feb 2007 23:33:51 +0530, Devdas Bhagat devdas-B/gC27/pXbteH41UXmfQsti2O/JbrIOy@public.gmane.org said:
On 28/02/07 10:05 -0600, Manoj Srivastava wrote:
snip>
chmod, ar and tar. rpm's need a special tool. Now, why is this important at all? Well, think of a classified environment, where you do not want to rely on the packaged tool to help you with forensics; but you have a trusted solaris box.
A unix system without cpio? RPM is essentially cpio with a specified header format.
Actually, no: it is a modified cpio. The implementation ispretty close, but it has some behaviors which are more to RPM's liking. If you take a plain old cpio from Solaris/Aix/HPUX et al you'll find that you can't really inspect/create rpm files.
inspect and extract yes, create not too easily..
Which is why we have rpm2cpio package, it converts the rpm tostandard cpio format. If it was a plain old cpio, you would not need rpm2cpio.
i was under a similar impression, but it ain't true.. see http://fedora.redhat.com/docs/drafts/rpm-guide-en/ch-extra-packaging-tools.h... for an example of shell and perl based rpm2cpio to remove the headers and other packaging information.
- dhawal
On 28/02/07 12:30 -0600, Manoj Srivastava wrote:
Actually, no: it is a modified cpio. The implementation ispretty close, but it has some behaviors which are more to RPM's liking. If you take a plain old cpio from Solaris/Aix/HPUX et al you'll find that you can't really inspect/create rpm files.
No, RPM is cpio encapsulated in packaging headers. If you remove the headers, you are left with plain old cpio files.
Which is why we have rpm2cpio package, it converts the rpm tostandard cpio format. If it was a plain old cpio, you would not need rpm2cpio.
rpm2cpio understands the RPM headers. As long as you know the packaging header length, you can simply use dd to extract the cpio file out.
Devdas Bhagat
-
Devdas Bhagat -
Dhawal Doshy -
Manoj Srivastava