ATOL: Comparison of binary package formats

28.3.2008 00:22 | Přečteno: 3360× | Linux

Author: Miloš Jakubíček (AToL - PV208, FI.MUNI)

The general purpose of binary packages (no matter what format they use), or to be more precise, package management systems, is to provide a prebuilt software including related metainformation in a from that can be used to enable the users and administrators to easily maintain (i. e. install, upgrade, remove etc.) the systems and applications programs so that the system remains consistent and its resources are used in a efficient way.

To achieve this, several standard methods are in use such as centralized package repositories, dependencies detection mechanisms, automated updates etc.

Comparison of binary package formats

There are various package formats which differ in their internal structure, features or available functional overlays for yet advanced management, but probably most widespread are RPM, deb and TGZ formats.

The RPM (the abbreviation stands for Redhat package management according to the original vendor) format is used e. g. in SUSE/openSUSE,Mandriva, CentOS and of course also RHEL and Fedora.

The deb(ian) format can be found especially on Debian-based distributions such as Debian or Ubuntu and TGZ is actually not a standardized package format as there are several (in most cases smaller) distributions (ArchLinux, Slackware, . . . ) which use tar&gzip to store their binary packages (in wide range of formats).

In this paper, I would like to concentrate on the comparison between deb and RPM format as these formats are most widespread nowadays and provide the richest features. There is also a conversion tool between RPM and deb called alien under development.

RPM

A standard way of packaging a program using RPM is to create a SPEC file containing all the metainformation about the package such as name, version, release (often abbreviated as N-V-R), runtime and buildtime dependencies, various installation scripts (called scriptlets) or triggers (event-driven scripts which can be executed when a specific action of another package occurs – like installation, update, uninstallation, . . . ) etc.

Further, an SRPM (source RPM) is created from the SPEC file and all source files which can be used to easily build the package or distribute the package sources. From this SRPM one or more final RPMs are created to be installed on the target systems. There is also useful program for automated checking well-formed SPEC files and RPMS called rpmlint.

deb

The deb package structure consist of three main components: first it is the debian-binary file containing the format version number, second, there is a control.tar.gz package entailing all the metainformation about the package similar to the RPM SPEC file, however separated into many files (such as the control file with general metainformation or installation scripts which are each in a separate file too).

Finally as third, there is a data.tar.gz package where all the binaries and other applications programs files are stored. The counterpart of RPM’s rpmlint is lintian.

Comparison

First of all, I should anticipate that there are several aspects which are hard to compare but important to consider. One of them is that each distribution usually defines a more or less precise set of packaging rules which influence the usability of their packaging systems in a big way. Moreover, users usually do not choose their distribution according to the package management system it uses and although it would be technically possible to use any of the package management systems on every distribution, there are hardly more users doing it.

From these (and yet more) reasons I’ll just point out some pros and cons of both RPM and deb package formats.

RPM

• + DeltaRPM which saves users traffic by downloading only deltas (diffs) between package versions
• + GPG signed packages
• + very good support for multilib (e. g. both 32bit and 64bit) systems
• + proper autogeneration of runtime dependencies in most of the cases
• - no way to handle suggested (not necessary) dependencies
• - non-standard format (rpm2cpio is needed for extraction)
• - rich features mean less simple design

deb

• + suggested dependencies
• + package priorities used to classify packages by their importance
• + standard format (tar)
• + some developers appreciate decentralized design of stored metainformation
• - no direct multilib support
• - no file dependencies

Conclusion

During my presentation and subsequent discussion, there were several valuable notices from my colleagues that I highly appreciate. Two of them I listed below:

• Although the deb packages can signed using GPG, this option is not used presently in Debian.
• Although the deb package format intended to be desktop-based and therefore it is interactive whereas the RPM package format intended to be server-based and as such it is strictly non-interactive, surprisingly in these days RPM is used rather on desktops than servers.

Reference

DEB:

http://en.wikipedia.org/wiki/Deb_(file_format) http://tldp.org/HOWTO/html_single/Debian-Binary-Package-Building-HOWTO/ http://www.linuxdevices.com/articles/AT8047723203.html http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html

RPM:

http://www.rpm.org http://en.wikipedia.org/wiki/RPM_Package_Manager http://docs.fedoraproject.org/drafts/rpm-guide-en/ http://genetikayos.com/code/repos/rpm-tutorial/trunk/rpm-tutorial.html http://www.ibm.com/developerworks/library/l-rpm1/ http://www.abclinuxu.cz/clanky/navody/rukovet-balice-rpm-i-uvod

TGZ:

http://www.abclinuxu.cz/clanky/system/balickovaci-system-arch-linuxu-1-formatbalicku

Others:

plkárna FI: thread Distro showdown - let your voices be heard (21. 9. 2007) http://kitenet.net/ joey/pkg-comp/ http://linux.die.net/man/1/alien http://www.howtoforge.com/converting_rpm_to_deb_with_alien        

Komentáře

[ATOL @ FI]

Přílohy:

• packaging-paper.pdf (102564 bytů)
• packaging-presentation.pdf (231993 bytů)

PDF version of presentation and paper

[Let_Me_Be]

Proc pro to radsi neudelate na ISu web + navazat na ostatni sluzby ISu - vsechno jde nastavit tak aby k tomu meli pristup i lide neprihlaseni do ISu.

[Marek 'marx' Grác]

Na ISe to samozrejme je a vždy to tam bude skôr ako tu, pretože tam nečakám na finálny dokument, ale zverejňuje sa to postupne. Rovnako je povolený prístup k materiálom pre každého (minimálne som niećo také nastavoval, aj keď možno nie na vśetko). Cieľom nie je obchádzať IS, ale získať komentáre a námety, to sa dá dosiahnuť jedine tak, že si to prečíta dostatok ľudí. A som si istý, že ich nájdem viac tu.

Nepoznám všetky služby ISu a neviem si predstaviť v čom by mohli byť prínosy, ale rád sa nechám poučiť.

[D-Evil]

Co se týká Debianu a podepsanejch balíčků, v testingu už to pokud vim běhá. Ovšem nejsem si jistej, jestli je to jen záležitost apt, nebo i dpkg, do hloubky jsem to nezkoumal. To ale ostatně teď nevim ani u rpm, jelikož moje poslední seznámení s timhle formátem bylo u Fedory 4, což už je hezky dlouhá doba.

[MJ]

Odpusťte balíkářskému diletantovi, ale co se myslí těmi file dependencies?

[Marek 'marx' Grác]

Je možné vytvoriť závislosť na konkrétnom súbore a nemusí nás zaujímať, ktorý balík ten súbor vytvoril. Niekto to považuje za feature a niekto za misfeature :)

[David Šmíd]

Nevím jak v DEB, ale v RPM může balík záviset pouze na symbolech. Každý balík automaticky poskytuje jako symbol své jméno včetně verze, své knihovny včetně verze a všechny soubory, které obsahuje + symboly definované tvůrcem balíku. Nechápu, co je na tom nebezpečného.

Copak DEB balík poskytuje pouze své jméno a nic jiného ?

[MJ]

Copak DEB balík poskytuje pouze své jméno a nic jiného ?

DEB to, pokud vím, řeší zavedením virtuálních balíčků a tagem Provides.

Ono to vlastně dává docela dobrý smysl: Když mám objekt, který může být obecně nabízen více balíčky, měl by být deklarován samostatně spolu s komentářem, co je zač a k čemu slouží.

[David Šmíd]

Jistě, to může být šikovný přístup. Nebo taky nemusí. Rozhodující je, že u RPM balíčků mám na výběr. Jestli to dobře chápu, tak DEB poskytuje pouze název balíku a to, co explicitně uvedu v Provides. Pokud bych chtěl poskytovat např. /bin/bash, musím to ručně uvést v Provides. Stejně jako třeba libz.so.1. V tom případě mi RPM přístup (implicitní poskytování souborů a knihoven) vyhovuje o trochu víc. Dá se lehce udělat multidistribuční RPM, které závisí třeba na /usr/bin/xsltproc a nemusí mě zajímat, jak se kde ten balík obsahující xsltproc jmenuje.

[Käyttäjä 11133]

No vzhledem k tomu, že různé distribuce používají na různé věci různá makra (to je ale růzností ) tak bych to nepovažoval za tak dobrý nápad. Třeba v případě sesktopových souborů... Nehledě na to, že build IMHO neumí pořešit zapsání konkrétního souboru v BuildRequires:.

[David Šmíd]

No tak zrovna při instalaci binárního balíčku nehrají makra vůbec žádnou roli. Makra se používají při sestavování (buildu) balíčků ze SRPM a ani tady to není žádný problém, neboť makra, jež je možné použít jsou přesně popsána ve specifikaci. Mohou se lišit pouze jejich hodnoty, ale od toho to snad jsou makra a ne konstanty. Fakt, že jsem neměl problém přeložit SRPM ze Suse na tak odlišné platformě jako je PCLinuxOS, hovoří za vše. Věta "build IMHO neumí pořešit zapsání konkrétního souboru v BuildRequires:" mi nedává vůbec žádný smysl, nevím co jsi tím myslel. Do "BuildRequires:" se, podobně jako do "Requires:", uvádějí symboly, které daný zdrojový balíček pro úspěšný build potřebuje. Build do toho tagu rozhodně nic nezapisuje a zapisovat nesmí, to je věc baliče.

[MJ]

Přijde mi velmi rozumné, aby balíčky měly explicitně určeno, jaký je jejich "interface", který poskytují ostatním, a co jsou interní záležitosti, do kterých nikomu nic není.

Ostatně, většinu balíků závisících na xsltprocu stejně zajímá xsltproc jako takový, nikoliv to, že je zrovna nainstalován v /usr/bin. Pokud bude v /opt/xsltproc/bin a povede tam cesta, je použitelný úplně stejně.

[David Šmíd]

To je spousta rozumných argumentů, proto se taky file depends používají jen velmi zřídka a file provides jsou zřetelně odlišeny od normálních provides (dokonce se nevypisují při dotazu rpm -q --provides), nicméně v mezních situacích mohou být užitečné (viz mnou popisovaný příklad). Pokud se dodržuje FHS, s distribučních zdrojů nainstalovaný xsltproc musí být v /usr/bin/. Neznám RPM distro, které by to mělo jinak. Nicméně daný balík se u mě jmenuje libxslt-proc a jinde se může jmenovat třeba libxsltproc nebo taky xsltproc nebo i xsltproc-utils. Pokud použiju file depend, nemusí mě to zajímat. Důležité je, že rozhodnutí je na mě, možnosti balíčkovacího systému mě neomezují. To co píšeš zní rozumně, ale nevidím to jako výhodu DEBu, spíše jako z nouze ctnost. File provides mohou být užitečné i jinak - např. snadno umožňují dotazovat se na obsah nenainstalovaných balíků.

[MJ]

Důležité je, že rozhodnutí je na mě, možnosti balíčkovacího systému mě neomezují. To co píšeš zní rozumně, ale nevidím to jako výhodu DEBu, spíše jako z nouze ctnost.

Já to také nevidím jako výhodu, ale přijde mi, že to ani není jakkoliv podstatná nevýhoda. Konec konců není od věci, když balíčkovací systém vynucuje jistou dávku štábní kultury :)

File provides mohou být užitečné i jinak - např. snadno umožňují dotazovat se na obsah nenainstalovaných balíků.

Jistě, ale to se dá zařídit i nekonečně mnoha jinými způsoby. On si nezávisle na tom nejspíš každý balíčkovací systém udržuje povědomí o tom, který soubor kterému balíčku patří.

[David Šmíd]

Tak tohle je z praktického hlediska skutečně nevýznamný rozdíl. Podle formátu balíčků bych si určitě distribuci nevybíral :). Ty věčné flamy RPM vs. DEB jsou mi k smíchu, celé je to o schopnostech tvůrce balíčku, nikoliv o formátu.

Jistě, ale to se dá zařídit i nekonečně mnoha jinými způsoby. On si nezávisle na tom nejspíš každý balíčkovací systém udržuje povědomí o tom, který soubor kterému balíčku patří.

Ano, ale to platí pouze pro nainstalované balíčky. U balíčků dostupných v repozitáři je to trochu složitější. pkglist APT-RPM repozitáře obsahuje i seznamy souborů (= file provides), o APT-DEB to, pokud jsem dobře informován, neplatí.

[MJ]

Ano, ale to platí pouze pro nainstalované balíčky. U balíčků dostupných v repozitáři je to trochu složitější. pkglist APT-RPM repozitáře obsahuje i seznamy souborů (= file provides), o APT-DEB to, pokud jsem dobře informován, neplatí.

A je vyhledávání v obsahu nenainstalovaných balíčků natolik důležité, aby bylo nutné kvůli němu (hrubým odhadem) zdvojnásobit velikost meta-dat balíčků, která si z repository každý musí stáhnout?

Není přirozenější naučit repository nějaký vyhledávací interface?

[David Šmíd]

V sekci main PCLOSu je asi 4900 balíčků, pkglist má velikost asi 10 MB (stahuje se komprimované, cca 1.2 MB), tj. poměr je asi 2 KB (0.25 KB v bz2) na jeden balíček. Je to dost. Nicméně při vytváření metadat repozitáře je možné přepínačem nastavit, aby se file provides nezahrnovaly do pgklistu. Já jsem našel jiné docela šikovné využití těchto "přebytečných" dat: implementoval jsem pomocí nich šikovný nástroj command-not-found známý z Ubuntu.

Není přirozenější naučit repository nějaký vyhledávací interface?

Je to určitě jedna z cest. Malou nevýhodu tohoto řešení vidím v tom, že skladba použitých repozitářů se na každém počítači může lišit a takhle by se dalo vyhledávat pouze z těch oficiálních.

[MJ]

Je to určitě jedna z cest. Malou nevýhodu tohoto řešení vidím v tom, že skladba použitých repozitářů se na každém počítači může lišit a takhle by se dalo vyhledávat pouze z těch oficiálních.

Já měl na mysli definovat rozhraní, které může implementovat každý repozitář. U těch oficiálních to samozřejmě Debian už dávno má.

[Miloš Jakubíček]

Tak tak...stojí za zmínění, co k tomu říkají Fedora Packaging Guidelines:

Rpm gives you the ability to depend on files instead of packages. Whenever possible you should avoid file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin. Using file dependencies outside of those directories requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency. Helping the depsolvers avoid this processing by depending on the package instead of the file saves our end users a lot of time. There are times when other technical considerations outweigh these considerations. One specific example is packages installing into %{_libdir}/mozilla/plugins. In this case, mandating a specific browser in your package just to own this directory could drag in a large amount of needless packages. Requiring the directory to resolve the dependency is the better choice.

[David Šmíd]

RPM - no way to handle suggested (not necessary) dependencies

Omyl, od verze 4.4 podporuje RPM tagy "Suggests:" a "Enhances:".

Příklad:

[root@pclinuxos /]# apt-get install psi
Reading Package Lists... Done
Building Dependency Tree... Done
Suggested packages:
  psi-i18n
The following NEW packages will be installed:
  psi
0 upgraded, 1 newly installed, 0 removed and 54 not upgraded.
Need to get 0B/3170kB of archives.
After unpacking 6967kB of additional disk space will be used.
Committing changes...
Preparing...                ########################################### [100%]
   1:psi                    ########################################### [100%]
Done.

[hydrandt]

Chceš hlásit chyby / překlepy, nebo tě tím nemáme zatěžovat? :)

[Marek 'marx' Grác]

Čo sa týka drobností tak ani nie. Ak sa tam opakujú nejaké veci, ktoré by mohli byť užitočné si pamätať tak som za.

[pele]

Jen takovy dotaz, je dependecies hell u rpm stale problem? Je, nebo byl to problem balickovaciho systemu nebo programu na spravu balicku? Pamatuju si ze me tohle postihlo u Mandrake 8.2 a to byl take duvod proc sem presel k Debianu, od te doby sem se k RedHat-like distribuci vyhybal.

[David Šmíd]

Není. Byl to problém špatně definovaných závislostí a slabých schopností tehdejších programů na správu balíčků (pokud vůbec správci balíčků existovali - viz RedHat).

---