A comparison of the deb, rpm, tgz, and slp package formats.

This is a comparison of the deb, rpm, tgz, and slp package formats, as used in the Debian, Red Hat, Slackware, and Stampede distributions, respectively. I've had some experience with each of the package formats, both building packages, and later in my work on the Alien package conversion program.

I've tried to keep this comparison unbiased, however for the record, I'm a fan of the deb format, and a Debian developer. If you discover any bias or inaccuracy in this comparison, or any important features of a package format I have left out, please mail me so I can correct it.

This comparison deals only with the package formats, not with the various tools (dpkg, rpm, etc.), that are used to deal with the packages. It also doesn't deal with the mechanisms used to build the packages (spec files, debian/ directories, etc).

Package format comparison table.

feature deb rpm tgz slp
Security, authentication, and verification
PGP-signed packages no yes no no
checksums yes yes no no
permissions, owners, etc yes yes yes yes
Usability by standard unix tools
recognizable by file yes [2] yes no no
unpackable by standard tools yes no yes yes [7]
metadata accessible by standard tools yes no N/A no
creatable by standard tools no no yes no
Metadata
dependencies yes yes no yes
recommendations yes no no no
suggestions yes no no no
conflicts yes yes no yes
virtual packages and provides yes yes no ??
versioned dependencies and conflicts yes yes no ??
complex boolean dependencies yes no [5] no no
file dependencies no yes no no
copyright no [6] yes no yes
grouping yes yes no yes
priority yes no no yes
Special files
config files yes yes no yes
documentation files no yes no no
Package programs
binary programs allowed yes no ?? yes
program output allowed yes no (??) ?? ??
interactive programs allowed yes no ?? ??
pre-install program yes yes no [1] no
post-install program yes yes yes yes
pre-remove program yes yes no [1] no
post-remove program yes yes yes no
verify program no yes no no
triggers no yes no no
Scalability
no hard-coded limits yes yes [3] yes no
new metadata yes yes [4] N/A no
new section yes no no no
format versions yes yes no yes

What is compared.

In this section I will explain the meaning of all of the qualities I am comparing in the various package formats.

Security, authentication, and verification

This section deals with ensuring that you know who created the package, and that you can check the package installed on your system to see if the files in it have ben modified since you installed it.

Usability by standard unix tools.

Recognising that it's important sometimes to be able to peer inside packages without using their package managers, this section compares how the various packages can be processed with tools available on any unix system.

Special files.

The ability to categorize files depending on what they are used for, so they can be dealt with in special ways.

Metadata.

Metadata is my term for the information about a package contained in the package. This includes things like the package name, description, and version number.

Package programs.

These are programs that are contained in the package, to be run when the package is installed, or uninstalled, or at other times.

Info available to package programs.

The programs may find various information useful to make decisions while they are running. Of course, all of them can look at what's currently on the filesystem, run other programs and look at the output, etc. This lists other information that may be useful.

[ not yet written ] 

old package version
etc

Scalability.

How well the package format is able to grow to meet future needs. This is of great importance. Many of the comparisons above have little value in the face of this section, because new package programs, new metadata fields, etc can all be added to a scalable package format with little difficulty.

Notes

[1] Supported by a version of this package format used by SuSE Linux.

[2] It is possible to make this work, but it doesn't right now. See debian bug #22854

[3] Technically, the rpm "lead" contains hard-coded limits on the package name, but the lead is no longer really used by anything except file.

[4] To be useful, you need to get a tag number assigned to your new piece of metadata.

[5] rpm's support depending on a list of packages, but do not support boolean OR.

[6] copyright info is included in debian packages, but not in an easily extractable format.

[7] assuming that bunzip2 is a standard unix tool, or that the package uses gzip compression instead. 





other stuff:

	relocatable
	support for arch name in metadata
		- arch indep packages
	multiple version of the same package can be installed simultaneously
		(is this really a package format issue?)