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
--
"Nuclear war can ruin your whole compile." Karl Lehenbauer
Manoj Srivastava <srivasta@xxxxxxx> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
