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

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.

What is compared.

Security, authentication, and verification

• PGP-signed packages
  Does the package format contain internal support for a PGP signature that can be used to verify who created it?
• checksums
  Are checksums available for all the files in the package?
• permissions, owners, etc
  Is information on the files in the package, their proper permissions, sizes, owners, groups, major and minor number (for devices), etc, available?

Usability by standard unix tools.

• recognizable by file
  Is the package format able to be recognized by file?
• unpackable by standard tools
  Can the package be unpacked using standard unix tools, without too much difficulty? (I add the proviso that it not be difficult because I don't mean can you edit a program file with vi and compile it with cc that is able to unpack the package, nor do I mean can you write a 20 line shell script that can unpack the package. The unpacking must be able to be accomplished quickly and must be a set of commands any unix person can remember without difficulty.)
• metadata accessible by standard tools
  If the package has some sort of metadata (ie, package name, description, version) contained in it, can this data be accessed by standard unix tools, without too much difficulty?
• creatable by standard tools
  Can a package be created using standard unix tools, without too much difficulty?

Special files.

• config files
  Are config files supported? These are files that the user will typically want to edit, so when a new version of a package is installed, the package manager should be able to know to leave them alone, or do something smart like prompt the user for what to do if they have modified the files, or at least make backups of the user's changes before overwriting them. (Maybe I need more granularity here?)
• documentation files
  Can documentation files be specially marked? This could be useful to help a user find documentation.

Metadata.

• dependencies
  A dependency says a package needs another package to be installed for the first package to work properly.
• recommendations
  A recommendation says a package will almost always need to have another package installed.
• suggestions
  A suggestion says a package may sometimes work better if another package is installed. The user can just be informed of this as a FYI.
• conflicts
  A conflict is a package that cannot be installed when this package is installed. One common reason is if the two packages both contain the same files.
• virtual packages and provides
  This means that there are so called "virtual packages", such as a web browser, or a mail delivery system, and packages can say they provide those virtual packages, while other packages can depend on the virtual packages.
• versioned dependencies and conflicts
  A package can depend on or conflict with (or recommend, etc.), a specific version of a package, or all versions > or < a given version.
• complex boolean dependencies
  This means that a package can depend on a package AND (another package OR a third package).
• file dependencies
  This means a package can require that some other package - any other package - be installed that contains a given file (like /bin/sh).
• copyright
  The package's metadata contains basic copyright information.
• grouping
  The package can be assigned to a group (ie, web browsers, libraries), which might be used to group the packages when viewing a list of available packages, etc. This makes it easier to deal with large groups of packages.
• priority
  The package can be assigned a priority, which says how important this package is to the system. For example, packages with high priority should be looked at carefully when you are setting up a system, but you can skip installing all the packages with low priority and still know you'll still get a functional unix system.

Package programs.

• binary programs allowed
  Must these programs really be scripts, or can compiled binaries be used as well?
• program output allowed
  May the programs output messages to the user to standard output and/or standard error?
• interactive programs allowed
  May the programs be interactive, ie, may they ask questions of the user and act on the user's reply? Note that this may not be a good thing, if you need to install an interactive program on many different systems, as you find yourself answering the same questions repeatedly.
• pre-install program
  A program to be run by the package manager before the package is installed on the system.
• post-install program
  A program to be run by the package manager after the package is installed on the system.
• pre-remove program
  A program to be run by the package manager before the package is removed.
• post-remove program
  A program to be run by the package manager after the package is removed.
• verify program
  A program to be run by the package manager when the state of the installed package is being verified.
• triggers
  This is a whole set of programs, that are run not when this package changes state, but when another package changes state.

Info available to package programs.

[ not yet written ]

old package version
etc

Scalability.

• no hard-coded limits
  Are there no limits hard-coded into the package format, that might prevent it from expanding to meet future needs? For example, are package names or versions limited to only 10 letters?
• new metadata
  Can new information (text, binary data, whatever) be added to the metadata easily, without changing the package format?
• new section
  Can the whole new sections be added to the packages, without changing the package format? For example, could the package format be expanded to have a pgp signature attached at the end, or to have a second set of data files, compiled for a different architecture or with different optimizations, attached the end? This is the ultimate test of how flexible the format is, I'm basically asking, was it designed to cope with unforeseen new requirements?
• format versions
  Is there some way to look at a package and tell which version of the package format it is using? In extreme cases, this means, the whole package format can be thrown out and redesigned but old tools will still be able to read enough of the packages to know they can't deal with them.

Notes

[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?)