Subject: RPM vs. DEB - which is better and why?

From: Omer Zak <[email-masked]>
Date: Wed, 29 Sep 2004 21:34:00 +0200

On the other day I read an article 
(http://www.manageability.org/blog/stuff/the-architecture-of-participation/view 
- whose subject is "The Architecture of Participation").  Among other 
things, it says "Just ask Red Hat, whose sole main contribution to the 
Linux world has been RPM.".

This leads me to question whether RedHad provided service or disservice 
to the world by providing RPM (rather than, say, reusing DEB).

Does anyone have the experience and intimate familiarity with both 
packaging formats needed to answer the above question.
                                              --- Omer
My own blog is at http://www.livejournal.com/users/tddpirate/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: omer mussaev <[email-masked]>
Date: Sun, 3 Oct 2004 06:38:57 -0700 (PDT)

> packaging formats needed to answer the above

This is rather long email...

A few years ago I had had to undrestand the internals
of RPM for my employer. 
Being a Debian user since 1996, I could not help but
to compare between
the two formats, so I think I may be qualified to
answer your question. 

Both systems allow a developer to create packages for
an application.
Both systems allow the developer to limit intended use
of the packages
to specific architecture/operating system. 
Both systems provide interface to explicitly specify
dependencies that
the packages has as well as means to enforce these
dependencies.

However, there are substantial differences:

Package Construction
========================================================================

RPM system assumes that there are vendors that create
packages, and then
there are users that install these packages. There are
dependencies
between the packages; it is role of distribution
authors to create set
of packages that mutually satisfy their respective
dependencies. 
Each RPM package has its own "spec" file - a
specification of
files that are included in the package, dependencies
that are to be met,
contact information for support/payments, scripts that
should be run
whenever the package is installed/uninstalled,
verification routines
etc. 

In addition to packaging, an RPM system provides means
for software
building. The very same "spec" file contains rules for
makefile
generation. During development phases the developers
may find very 
convinient to create RPM specifications once and have
the compile 
server produce installable distributables after each
build.  It has a
lot of positive effect on software quality etc.

This model is well suited for commertial software
vendors that prefer
to control as much of the distribution/package
creation process as
possible.

Debian system assumes much more of the development
process:

In addition to developers that create software, there
are package
maintainers. While a developer may be a package
maintainer of software
he develops (e.g. [email-masked] ), roles are
definitely different.
It's the package maintainer who creates a package,
and, as such, he
must be responsible for any problems the package may
introduce (unmet
dependencies, readiness for new foundation libraries,
support for I18N
or IDN or whatever). 
However, unlike RPM world, in order to put the package
into
distrubution, a master list of packages must be
created. This list
(maintained by "Debian Czars") represents a snapshot
of a system state.

The DEB system does not specify any build rules. It is
possible, of 
course, to deploy whatever source change managment
system the developer(s)
may find appropriate to create the software. One may
find it very nice,
and, to some extent "right" that a package development
does not force
any "mechanism" of software construction upon a
developer, but allows
the package maintainer to decide.

Package Installation
========================================================================

Both systems have a client software that is
responsible for installing
software, removing software, performing software
updates and quering the
system about installed software packages. 

Both systems support relocateable packages - packages
that do not insist
on specific location.

There is two substantial differences between the two:

RPM system disallows user input during
installation/deinstallation. The
documentation claims that user input is disallowed to
support unattended
installations. It may, however, force the developers
to invent their own
solutions once they do have to ask the user some
questions. The tradeof
beteween unattended installation that requires
post-installation
configuration and atteneded installation that doesn't
require any is
indeed an architectural issue.

Another difference is the "alternatives"/"virtual
packages" approach
taken by DEB. The idea is that if some software needs
a web server, than
it need a web server, not nessesarily "apache" or
"boa" or "goahead".
Likewise, if a user wants a vi, he may be satisfied by
nvi, by vim or by
viper. This kind of a "is a" relationships between
packages is answered
in DEB sybsystem in a elegant way - there is a
/etc/alternatives
subdirectory in a user's filesystem. Each package that
provides
functionality of some generic software (e.g. vim that
"provides" vi)
registers itself in that /etc/alternatives directory
as an "alternative"

Package Maintainence
========================================================================

RPM system stores the package metainformation in a
database-like
structure. This allows performing queries in a
SQL-like manner.

DEB system stores the package information as a set of
plain text files.
This scheme is very robust, and allows using system
tools to find out
the metainformation.

> Omer
> My own blog is at
> http://www.livejournal.com/users/tddpirate/
> 

=====
--
o.m.

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Tzafrir Cohen <[email-masked]>
Date: Mon, 04 Oct 2004 13:42:22 +0200

> Linux world has been RPM.".

Much an overstating. 

And there are some layers on top of rpm to which RH has not contributed
enough (apt/yum/whatever) as it was busy with its own up2date and with
bloating rpm...

> to the world by providing RPM (rather than, say, reusing DEB).

RPM was designed before DEB. So the question is rather moot.

My 2c regarding rpm vs. deb:

The debian build sytem is much more complex, but more straight-forward
in its approach. 

With rpm it is much easier to get started. And it is also much easier to
get a recontructable package: all the builng is done in a separate tree,
not just the insallation.

Ah: and with debs you never have to mess with cpio.

> Yahoo! Groups Links

-- 
Tzafrir Cohen                       +---------------------------+
http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend|
mailto:[email-masked]       +---------------------------+

---

From: Tzafrir Cohen <[email-masked]>
Date: Wed, 06 Oct 2004 09:39:19 +0200

On Sun, Oct 03, 2004 at 06:38:57AM -0700, omer mussaev wrote:
> RPM system assumes that there are vendors that create packages, and then
> there are users that install these packages. There are dependencies
> between the packages; it is role of distribution authors to create set
> of packages that mutually satisfy their respective dependencies. 
> Each RPM package has its own "spec" file - a specification of
> files that are included in the package, dependencies that are to be met,
> contact information for support/payments, scripts that should be run
> whenever the package is installed/uninstalled, verification routines
> etc. 

An rpm source package consists of typically one source tarball, a spec
file, and optionally a number of patches. The spec file is basically
equivalent to the debian/ subdirectory.

See also http://www.rpm.org/max-rpm/ch-rpm-philosophy.html

> 
> In addition to packaging, an RPM system provides means for software
> building. The very same "spec" file contains rules for makefile
> generation. During development phases the developers may find very 
> convinient to create RPM specifications once and have the compile 
> server produce installable distributables after each build.  It has a

IMHO rpm is much more pedantic than deb about creating a reproducable
build.

> 
> This model is well suited for commertial software vendors that prefer
> to control as much of the distribution/package creation process as
> possible.
> 

Why only for them?

> In addition to developers that create software, there are package
> maintainers. While a developer may be a package maintainer of software
> he develops (e.g. [email-masked] ), roles are definitely different.
> It's the package maintainer who creates a package, and, as such, he
> must be responsible for any problems the package may introduce (unmet
> dependencies, readiness for new foundation libraries, support for I18N
> or IDN or whatever). 

You probably don't follow the "rpm" distros. They generally have such
maintainers. Though they tend to be full-time developers with many
packages in responsibility. 

> However, unlike RPM world, in order to put the package into
> distrubution, a master list of packages must be created. This list
> (maintained by "Debian Czars") represents a snapshot of a system state.

This is something completely different. The people of Debian don't all
work at one company and lack quick methods of communication. Thus they
had to establish more formal methods for everything. But then again, you
have had Redhat RawHide (a snapshow of the development distribution) for 
years.

> 
> The DEB system does not specify any build rules. 

Huh? I thought that this was the point to say debian/rules ;-)

The rules file is a regular makefile. It may contain anything a makefile
can contain. However to maintain consistency there are some standard
commands at the disposal of the package developer. the advantage of
using those commands is that when the policy of the distro changes, you
only have to rebuild the package.

Not surprisingly, RPM had such a thing since day one. THe RPM spec file
is written in its own text processing language (see
/usr/share/doc/rpm*/MACROS , IIRC) . Many macros are not even written in
the spec file and run by the rpm command.

There are a number of problems with that system:
1. highly undocumented.
2. The lack of standard macros accross distros

None eof the two is a generic problem with the system, though.

>                                                It is possible, of 
> course, to deploy whatever source change managment system the developer(s)
> may find appropriate to create the software. 

One distro that does so is PLD (Polish(ed) Linux Distribution). Take a
look at their rpm changelogs.

On the other hand, since you raise that subject, one of RedHat's
veterans is now working on a system that combines source control,
packageing and the equivalent of apt. Anybody with the URL here?

>                                          One may find it very nice,
> and, to some extent "right" that a package development does not force
> any "mechanism" of software construction upon a developer, but allows
> Both systems have a client software that is responsible for installing
> software, removing software, performing software updates and quering the
> Both systems support relocateable packages - packages that do not insist
> on specific location.

Is this feature supported in practice? Used in practice?

> RPM system disallows user input during installation/deinstallation. The
> documentation claims that user input is disallowed to support unattended
> installations. It may, however, force the developers to invent their own
> solutions once they do have to ask the user some questions. The tradeof
> beteween unattended installation that requires post-installation
> configuration and atteneded installation that doesn't require any is

There is one other issue here: a naive packager would only think about
the first post-nstallation. Maybeeven about an uninstallation. But what
about an upgrade?

Another interesting anecdote: up until now, Debian has had no automatic
instllation procedure. The new Debian installer filnally have something
(a preseed file) and it is still highly immature. Its main problem is
that it reacts poorly to changes.

As a result, I believe that there is much bigger a chance for debian
installation to fail in the middle, as this is less disturbing for the
developers.

> 
> Another difference is the "alternatives"/"virtual packages" approach
> taken by DEB. The idea is that if some software needs a web server, than
> it need a web server, not nessesarily "apache" or "boa" or "goahead".
> Likewise, if a user wants a vi, he may be satisfied by nvi, by vim or by
> viper. This kind of a "is a" relationships between packages is answered
> in DEB sybsystem in a elegant way - there is a /etc/alternatives
> subdirectory in a user's filesystem. Each package that provides
> functionality of some generic software (e.g. vim that "provides" vi)
> registers itself in that /etc/alternatives directory as an "alternative"
> 

The laternatives is not part of deb. As such it has been adopted by
other distros, at least Mandrake and RH/Fedora.

Virtual packages is something different. Having them is mostl a matter
of policy (forcing all the relevant packages to depend on "httpd"
because there may be actually an http server besides apache. I figure
that for Mandrake or RedHat this was not really an issue. Maybe for
SuSE).

Something that rpm does lackain that field is a dependency on "a || b" .

> RPM system stores the package metainformation in a database-like
> structure. This allows performing queries in a SQL-like manner.

The packages are in a Berkely DB. 
The downside is that rpm requires that specific library just to get
going. The internal database formay has changed a number of times and
this was a pain.

The upside is 'rpm -qfl' and the like.

> 
> DEB system stores the package information as a set of plain text files.
> This scheme is very robust, and allows using system tools to find out
> the metainformation.