ATOL: Comparison of binary package formats (diskuse)

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

---