Binary Package Formats Compared

jjaimon writes "There is a document on different package formats used in Linux/Unix systems. Worth reading." Another reader sends in this guide to creating Debian packages which seems apropos here.

Comments

Because of /.ing

[mschoolbus]

Comparing Linux/UNIX Binary Package Formats This is a comparison of the deb, rpm, tgz, slp, and pkg package formats, as used in the Debian, Red Hat, Slackware, and Stampede linux distributions respectively (pkg is the SVr4 package format, used in Solaris). 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. Several people have already done so. I'm also looking for data to fill in the places marked by `?'. This comparison deals only with the package formats, not with the various tools (dpkg, rpm, etc.), that are used to deal with and install the packages. It also does not deal with source packages, only binary packages. Package format comparison table. feature deb rpm tgz slp pkg Security, authentication, and verification signed packages yes[1] yes no no no checksums yes yes no no yes permissions, owners, etc yes yes yes yes yes Usability by standard linux tools recognizable by file yes yes no no yes data unpackable by standard tools yes [3] no [4] yes yes [5] no [6] metadata accessible by standard tools yes no N/A no no [6] creatable by standard tools yes no yes no no Metadata dependencies yes yes no yes yes recommendations yes no no no no suggestions yes no no no no conflicts yes yes no yes yes virtual packages and provides yes yes no ?? no versioned dependencies and conflicts yes yes no ?? yes boolean package relationshipss yes no [8] no no no file dependencies no yes no no no copyright info no [10] yes no yes yes grouping yes yes no no yes priority yes no no yes no Special files config files yes yes no yes yes documentation files no yes no no yes [11] ghost files no yes no no no Package programs binary programs allowed yes no ?? yes no pre-install program yes yes no [12] no yes post-install program yes yes yes yes yes pre-remove program yes yes no [12] no yes post-remove program yes yes yes [12] no yes verify program no yes no no no triggers no yes no no no Scalability no hard-coded limits yes yes [13] yes no no [6] new metadata yes yes [14] N/A no no [6] new section yes no no no no [6] format version data yes yes no yes no [6] What is compared. 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. signed packages Does the package format contain internal support for a GPG or 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 linux 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 linux system [2]. recognizable by file Is the package format able to be recognized by file? data unpackable by standard tools Can an experienced user, when presented with a package in this format, extract its payload using only tools that will be on any linux system? They can remember a few facts to help them deal with the format, but remembering file offsets and stuff like that is too hard. 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 tools, without too much difficulty? creatable by standard tools Can a package be created using standard tools, without too much difficulty? Metadata. Metadata is my term for the information abo

Re:RPM is best because of the support

[getoblstr]

Try Debian or a Debian based distribution. Apt-get and dpkg are just great. I used to use Red Hat but I use Debian now and would never go back.