Balíčky pro Debian - 2 (popisy balíčků)

10. 6. 2008 | Michal Čihař | Návody | 6258×

Veškeré informace o balíčku se nacházejí v souboru debian/control. Co všechno tento soubor musí obsahovat a co vše do něj můžeme napsat?

Obsah

• Zdrojový balíček
• Binární balíček
  • Závislosti
  • Další položky
  • Popis balíčku
• Závěr

Soubor debian/control je jednoduchý textový soubor ve formátu odpovídajícím RFC-2822, ve kterém jsou základní informace o balíčku. Informace jsou vždy zadány ve formě jméno: hodnota a bez tohoto souboru se prostě neobejdeme. Ale pojďme už od teorie a podívejme se na debian/control z našeho ukázkového balíčku photo-uploader rozebraném v minulém díle:

Source: photo-uploader
Section: graphics
Priority: extra
Maintainer: Michal Čihař <nijel@debian.org>
Build-Depends: debhelper (>= 5.0.37.2)
Build-Depends-Indep: python-dev, python-central (>= 0.5), python-pycurl
Standards-Version: 3.7.3
XS-Python-Version: current
Vcs-Svn: svn://svn.cihar.com/debian-photo-uploader
Vcs-Browser: http://viewsvn.cihar.com/debian-photo-uploader
Homepage: http://cihar.com/software/photo-uploader/

Package: photo-uploader
Architecture: all
Depends: ${python:Depends}, python-pycurl
XB-Python-Version: ${python:Versions}
description: Command line photo uploader
 Photo uploader is a command line utility (and Python module) for
 uploading photos to minilabs for printing or to any service for image
 hosting. It currently supports only a few minilab services in Czechia 
 and some hosting services like ImageShack, but can be easily extended 
 to support others.

Jak vidíte, soubor je rozdělen prázdným řádkem do dvou částí. První se týká zdrojového balíčku a informace tam uvedené budou ve výsledném zdrojovém balíčku v souboru photo-uploader_0.5-1.dsc. Druhá část binárního balíčku se při vytváření balíčku uloží do něj. Pokud by zdrojový balíček vytvářel více binárních, bude takovýchto sekcí obsahovat více, jednu pro každý binární balíček. Některé hodnoty jsou společné pro obě sekce a je možné je uvést jak u zdrojového, tak u binárního balíčku. V tom případě mají informace u binárního balíčku přednost.

Zdrojový balíček

První část tedy popisuje zdrojový balíček, začneme pěkně od začátku.

• Source určuje jméno zdrojového balíčku. Pravděpodobně zůstaneme u názvu, který používá autor. Jedná se o povinnou položku.

• Hodnotou Section určíme, jaké oblasti se balíček týká. Nástroje pro správu balíčků umožňují balíčky procházet podle sekcí a tím usnadní uživateli výběr. Pokud balíček z nějakých důvodů nemůže být začleněn do hlavního repositáře (main) a musí být v contrib nebo non-free, bude zde tento repositář uvedený před lomítkem, tedy například non-free/x11. Jedná se o doporučovanou položku.

• Priorita (Priority) určuje, jak moc je balíček důležitý. Většinou si vystačíme s extra nebo optional (moc velký rozdíl mezi nimi není). Jedná se o doporučovanou položku.

• Další položka (Maintainer) uvádí, kdo má balíček na svědomí. Jedná se o povinnou položku.

• Následující dva řádky se závislostmi (Build-Depends a Build-Depends-Indep) určují, které balíčky musí být přítomny pro kompilaci našeho balíčku. Build-Depends-Indep se týká jen zdrojových balíčků vytvářejících binární balíčky nezávislé na architektuře a určuje, co je potřeba pro vytvoření těchto balíčků. Položka není povinná, ale těžko se bez ní obejdeme. Na podobné téma ještě můžeme použít Build-Conflicts a Build-Conflicts-Indep, například pokud kompilace selže při nainstalování nějakého dalšího balíčku.

• Standards-Version identifikuje verzi Debian Policy, které balíček odpovídá. Jedná se o doporučovanou položku a měla by být udržována na aktuální verzi Debian Policy.

• XS-Python-Version se týká jen balíčků pro Python a prozatím jej budeme ignorovat. Veškeré parametry začínající na XS- nejsou přímo podporovány dpkg, ale jejich jméno a hodnota jsou zkopírovány do dsc souboru.

• A teď se dostáváme k poměrně čerstvým novinkám ve zdrojovém balíčku. Z polí Vcs-* se můžeme dozvědět, kde správce balíčku udržuje svoji pracovní verzi. Vždy se jedná o odkaz na systém správy verzí a Vcs-Browser obsahuje odkaz na webové prohlížítko daného repozitáře. Tato položka je nepovinná.

• Poslední hodnota Homepage překvapivě určuje domovskou stránku zabaleného projektu. Tato položka se použije i pro všechny binární balíčky (pokud nemají uvedenu vlastní) a je nepovinná.

Binární balíček

Pro každý binární balíček bude v souboru debian/control právě jedna sekce se jménem balíčku uvedené za klíčovým slovem Package. Jména balíčků ne vždy přímo odpovídají tomu, jak se balený program jmenuje, protože je potřeba mít v distribuci konzistentní pojmenování podobných věcí. Proto se třeba moduly pro Python vždy jmenují python-jménomodulu a pro Perl zase libcosi-perl. Pokud nevíte, jaké jméno zvolit, a nechce se vám hledat policy pro příslušnou skupinu balíčků, najděte si něco podobného a inspirujte se.

Trochu speciálním případem jsou sdílené knihovny. U těch musí jméno balíčku odpovídat soname dané knihovny. Tím je zajištěna možnost mít současně nainstalované různé verze jedné knihovny, což je v systému používajícím rolling updates naprostá nutnost. Knihovna libc.so.6 tedy bude v balíčku libc6 a libgtkspell.so.0 zase v libgtkspell0. U vývojových balíčků už obvykle není potřeba mít současně nainstalované různé verze (ale najdou se i výjimky, třeba knihovna libdb nechvalně proslulá nekompatibilitou jednotlivých verzí), a proto stačí jediný, například libgtkspell-dev.

Další položka Architecture určuje architekturu binárního balíčku. Pokud nebalíme něco, co funguje jen na některé architektuře, vystačíme si s hodnotami all a any. Hodnota any určuje balíček, který lze kompilovat pro každou architekturu, all oproti tomu balíček nezávislý na architektuře, například data nebo dokumentaci. Jedná se o povinnou položku.

Závislosti

Závislosti balíčku získáme z položky Depends. Protože však jsou vývojáři tvorové líní, nemusíme tam uvádět vše, protože debhelper je schopný některé závislosti najít automaticky a pak je nahradit do tohoto pole. Pro tento účel se používají v poli Depends proměnné - tak, jako je v tomto případě použito ${python:Depends}. U kompilovaných balíčků budeme chtít použít ${shlibs:Depends}, což se nahradí jména balíčků s knihovnami, se kterými je náš program (nebo knihovna) slinkován. Takovýchto substitucí existuje více, obvykle bývá zvykem uvádět ještě ${misc:Depends} a pak ještě můžeme použít informace o verzi právě kompilovaného balíčku ve formě ${source:Version} a ${binary:Version}. Závislosti v balíčku samozřejmě povinné nejsou, ale asi se bez nich neobejdeme.

Kromě striktní závislosti umožňuje Debian ještě mnoho dalších vztahů mezi balíčky: Recommends, Suggests, Enhances, Pre-Depends a Conflicts. Conflicts značí konflikt balíčků, Pre-Depends závislost, která je potřeba již při instalaci (pokud používáme ve skriptících při instalaci nějaký nástroj, měli bychom ho tam uvést).

Recommends a Suggests jsou jen volitelné závislosti, přičemž Recommends je silnější závislost a výchozí chování APT je používat Recommends jako závislost a tyto balíčky tedy budou nainstalovány, pokud si uživatel nezvolí jinak. Závislost Suggests je nejslabší a je na uživateli, zda si tyto balíčky nainstaluje.

Poslední vztah je Enhances, což je vlastně opačná varianta Suggests. Jedná se tedy o slabou závislost, ale v opačném směru.

Další položky

V námi zkoumaném balíčku ještě vidíme XB-Python-Version. Platí to samé jako pro variantu s XS- ve zdrojovém balíčku, tedy týká se jen balíčků pro Python a prozatím si jí nemusíme všímat.

Další položkou, se kterou se můžeme setkat, je Essential. Pokud má hodnotu yes, je balíček považován za nezbytný k funkci systému a při jeho odstraňování musí uživatel vynaložit větší úsilí na jeho odinstalování.

Popis balíčku

Poslední položkou je popis balíčku - Description. První řádek určuje krátký popisek, další odsazené řádky jsou dlouhý popisek. Pokud chceme delší popisek rozdělit do odstavců, je potřeba odstavec nahradit tečkou a zachovávat odsazení, například:

Description: Some package
 Very long description of some package, which needs
 more paragraphs.
 .
 Second paragraph is completely useless here.

Závěr

Tím jsme probrali základní možnosti týkající se toho, co uvést v souboru debian/control a příště se podíváme do dalších.

       

Komentáře

[Alcor]

Super, jen tak dál ...

[laco]

Seriál jo. Horší je, že Ubuntu bere všechno od Debianu, ale ubunťácké balíčky nejdou v Debianu zpětně použít. Ubuntu je sice polidštěný Debian, ale zdá se, Ubuntu bere víc než dává.

[David Jaša]

Chcete-li balíček z Ubu do Debu, tak si stáhněte zdrojový a překompilujte u sebe. Stejný postup platí i pro opačný směr. :-P

[Kovář David]

Tak váš názor je takový open source naruby. Navíc si neuvědomuji, že by vývojáři Debianu vyráběli své balíčky pro Ubuntu. Tak proč by vývojáři Ubuntu měli vyrábět balíčky pro Debian? Ubuntu balíčky jsou k dispozici stejně jako Debianí, tak je vezměte a přeneste do Debianu. Tady na to máte super návod. To je open source, vy si to trochu pletete.

[Pev]

Navíc si neuvědomuji, že by vývojáři Debianu vyráběli své balíčky pro Ubuntu.

No známá pravda je, že naprostá většina z více než 10 tis. balíků Debianu je v Ubuntu použitá beze změny.

Dokazuje to text u jednotlivých balíků na http://packages.ubuntu.com/ :

Original Maintainers (usually from Debian):

Ideální by byla větší (oboustranná) spolupráce mezi Ubuntu a Debianem, zatím je to IMHO jen Debian => Ubuntu.

Příkladem použití by mohl být balík pgadmin3. V Ubuntu je už delší dobu, do Debianu se dostal do experimentalu teprve 2008-05-26. Zda to v Debianu vyselo na wxwidgets verze 2.8 nevím (dlouho v Debianu nebyla), ale zřejmě spolu vývojáři nespolupracovali.

BTW: Nemá náhodou Ubuntu některé názvy balíků jiné?

[Michal Čihař]

To byl problém wxwidgets 2.8, resp. s jeho správcem v Debianu, který prohlásil, že verze 2.8 je špatná a on jí rozhodně do Debianu dávat nebude. Zrovna tahle věc je spíš problémem Debianu než Ubuntu .

Názvy balíků by měly být stejné (možná až na některé metabalíky).

[Jan Včelák]

Ubuntu se o balicky stara daleko lepe. Kdyby s tou organizaci a zavislostma Debianu trosku pomohli, zase bych zacal Debian pouzivat. Pomalu uz davam Ubuntu i na servery...

[Pev]

No já nevím, nechci Ubuntu nějak hanit, sám ho na jednom serveru také používám (nezvolil jsem ho já), ale už jenom bug nefunkčních dpkg-reconfigure locales mi ukazuje, že to není úplně dobře udělaná distribuce. (A není to samozřejmě jen tohle, jsou to kolikrát drobnosti, ale je jich víc.)

Já mám opravdu lepší zkušenost s Debianem, a to jak na serveru, tak na desktopu.

[Miki]

hmm, tak kdy už konečně někomu dojde, že velkým problémem Linuxu je naprosto příšerná roztříštěnost všeho. Teď konkrétně u balíčkovacích systémů. A Ubuntu v tom dělá ještě větší bordel tím, že vytváří další podsystém v jednom už vytovřeném. Ať už má Ubuntu v rozšiřování povědomí o Linuxu sebevětší zásluhy, tohle je věc která mi na něm hodně vadí.

[David Jaša]

Pán či dáma o balíčkovacích systémech ví prd a proto kritizuje neexistující problém, co?

[Miki]

Hmm, pokud jsem tedy napsal nějaký blábol, pak se omlouvám. V tom případě bych ale rád věděl, proč na většině stránek, kde je jsou ke stažení binární balíčky je jeden balíček rpm pro všechny od něj odvozené distribuce a balíčky deb jsou typicky dva. Pro Debian a Ubuntu. Jako uživatele mě to dost mate.

[David Jaša]

Ty různé balíčky jsou téměř vždy zkompilované z téhož zdrojového balíčku. Většinou je jich taky víc než dva, pro každou podporovanou verzi je samostatný. Jak řeší rozdíly v závislostech* RPM netuším, ale nějak to musí mít také ošetřené.

* kvůli kterým má deb pro každou distribuci/verzi samostaný balík

[jhr]

rpm resi zavislosti na bazi capabilit, coz jsou bud primo jmena so knihoven ktere prislusne baliky maji jako provides, nebo ruzne promenne ci primo cesty k souborum. nekdy si myslim ze jde o neco lepsi reseni nez ma deb nekdy ne. rozhodne z toho plyne ze na debu lze castecnym upgradem systemu napachat skody ktere by rpm asi nedovolilo. jelikoz pouzivam primarne deb a to i pracovne, tak vim ze na to staci jen myslet a lze se casto vyvarovat problemu.

[Michal Čihař]

Co mi to jenom připomíná…

[Jirka P]

Ty v rom repozitáři nemáš upstream ani patche. Moh bys (ne)výhody tohohle řešení rozvést?

Třeba co jsem čet nějaký tutoriál od Manoje Sristavy, ten má v repozitáři balíčku opatchovaný zdroják, ale ne adresář debian.

Je lepší spravovat patche v gitu/svn a mít je v balíku naházený v diff.gz nebo mít patche i v balíku v quiltu a zapomenout na repozitář, protože patche se v repozitáři tak, aby byly přímo ve stromu spravovat nedají? Je nějaká třetí možnost?

[Michal Čihař]

Počkej si na další díly .