Re: Time to fight for our beloved DEB format!
Matti Airas wrote:
> but a policy issue. While dpkg uses fairly robust text file format,
> rpm uses Berkeley DB's, which are very established as well, and
> somewhat faster and more compact than dpkg text files. Etc etc. Both
> packaging formats have their pros as well as cons. What ensures the
> high quality of Debian, is its policy. Still, a packaging format
> should not be seen as a religious issue.
The biggest problem with the rpm package format is that it changes at
every major Red Hat release.
I'm actually a bit scared at the way that the LSB chose to refer to the
rpm package format:
as defined in the appendix of Maximum RPM
Is that v3? I'd have to download the book to check, but what happens if
a new version of maximum rpm comes out that documents v4 rpm's? Yuck.
I'm not used to seeing that kind of dependance on external, unversioned
documents in a standard.
> 2) Assuming that I am not misinformed about the functional
> compatibility of dpkg and rpm, a LONG TERM goal for transforming
> Debian to rpm base is issued. This would include adding rpm support
> for all Debian package management tools, and transition tools for the
> database contents, etc.
Sure, no problem, go ahead. As soon as you have modified rpm to meet all
the tick marks that are in deb's column at
http://kitenet.net/alien/pkg-comp/, that is.
Some are quite trivial: Adding Recommends and Pre-Depends and Suggests
and Priority fields to the package format. Allowing binary programs as
maintainer scripts.
Others are less trivial: Ability to be unpacked by standard unix tools.
Supporting our more complex dependancy format.
And others are killers: Ability to add a new field to the package
metadata at any time[1], ability to add an entire new section at any
time[2].
[1] Unlike the deb format, the rpm package format does not store the
textual names of fields in the packages' metadata structure.
Instead, fields are identified by way of a "tag" -- a number which
is an index into a static list of fields, that is built into rpm
(see lib/rpmlib.h). Now, consider that the rpm format is basically
controlled by Red Hat. Now think for a bit about what we at Debian
would need to do if we wanted to add some field that Red Hat, for
whatever reason, did not want to add. Is this FUD? Well, maybe. But
I sure prefer open formats that let anyone add any tags they want
without having to go through a central authority.
[2] See [1]. It's even worse with respect to adding a whole new major
section to the format. Basically impossible unless you stick it in
the header as described in [1]. And that may well not always be
a good idea (think packages that have multiple payloads for
different architectures or something).
--
see shy jo, maintainer of rpm and alien
Reply to: