Balíčky pro Debian - 12 (závěr aneb co se jinam nevešlo)

23. 10. 2008 | Michal Čihař | Návody | 4072×

Předchozích jedenáct dílů vás provedlo základy vytváření balíčků pro Debian. Tento poslední díl je jakási všehochuť doplňující některé chybějící informace a drobné změny, ke kterým došlo, než byl seriál dopsán, nebo které se chystají.

Obsah

• Verze balíčků
  • Epocha
  • Verze
    • Přebalení tarballu
    • SVN snapshoty, alfa verze a podobné
  • Revize, nativní balíčky
    • NMU
    • Binární NMU
    • Backporty
• Jaké změny hrozí?

Verze balíčků

Verze balíčku je ve většině případů jen kombinací verze zabaleného softwaru a revize balíčku pro Debian, tedy něco jako 1.2.3-1. Bohužel ne vždy je to tak jednoduché a verze může klidně narůst do obludností jako například 3:3.10.dfsg.4~r3724-1.1+b1. Obecně můžeme popsat verzi jako [epocha:]verze_programu[-revize_balíčku], kde jediná povinná část je verze programu, ostatní nemusí být použity.

Porovnávání verzí postupuje zleva doprava a vždy je nejdříve lexikálně porovnána nenumerická část a poté numerická část jako čísla a tyto kroky se opakují, dokud je co porovnávat. Nevyplněná epocha se považuje za 0, stejně tak jako nepoužitá revize. Lexikografické porovnání je trochu zvláštní -- nejnižší hodnotu má tilda (~), která má dokonce menší hodnotu než prázdný text, poté všechna písmena a nakonec ostatní povolené znaky (+, ., případně - a :). Porovnání si můžete vyzkoušet pomocí dpkg --compare-versions.

Epocha

Epocha se používá obvykle za situace, kdy se z nějakého důvodu změnilo číslování verzí programů a novější verze mají nižší číslo než starší. Epocha obsahuje jediné (obvykle malé) celé kladné číslo. Například při modularizaci X.org spousta balíčků přešla z verze 7.0 na 1.0 a správce balíčků by si tedy myslel, že se nejedná o novější verzi. Přidáním epochy se porovnávají verze 7.0 a 1:1.0, kde první sice nemá explicitní epochu uvedenu, ale použije se implicitní hodnota 0. Tímto trikem tedy zajistíme, že verze 1.0 bude považována za novější než 7.0.

Verze

Verze programu je obvykle to, co používá jeho autor. Nicméně občas dojde na situaci, kdy nemůže být verze použita přímo, ale musíme jí trochu přiohnout. A jak můžete vidět z příkladu v úvodu, je zde prostoru pro ohýbání dost.

Přebalení tarballu

Pokud je potřeba tarball z nějakého důvodu (obvykle licenčního) přebalit oproti tomu, který šíří původní autor, musíme to vyznačit ve verzi. Toto se provede přidáním textu dfsg (zkratka Debian Free Software Guidelines) do verze. Pokud očekáváme, že na první pokus nebude vše ještě úplně v pořádku, můžeme použít i verzi přebalení. Verze balíčku pak může vypadat například 3.10.dfsg.4. Jako oddělovací znak mezi verzí a textem dfsg se kromě tečky může použít i plus, záleží na preferenci autora (verze tedy může být 1.2+dfsg).

Pokud je tarball přebalen z jiných důvodů než kvůli licencím, místo textu dfsg se použije text debian, ale tato situace není moc častá.

SVN snapshoty, alfa verze a podobné

Pokud se jedná třeba o snapshot ze SVN nebo alfa verzi, musíme to nějak zohlednit ve verzi. Pro tyto případy se používá už dříve zmíněná tilda, která zajistí, že verze 3.10~alpha1 bude menší než 3.10. Podobně snapshot verze 1.2 pojmenujeme 1.2~r1234 a při vydání finální verze můžeme použít verzi 1.2.

Revize, nativní balíčky

Revize balíčku je obvykle jen kladné celé číslo, ale při dále zmíněných situacích se může zkomplikovat. Revize se nepoužívá jen pro nativní programy, tedy věci vyvíjené přímo pro Debian (tedy tak by to mělo být, nicméně skutečnost je občas poněkud jiná).

NMU

Pokud není správce balíčku k dispozici, nebo nereaguje dostatečně rychle na kritické chyby, může jiný Debian developer zaskočit a nahrát do archívu opravenou verzi. Tomuto se říká Non-Maintainer Upload a zkracuje se to NMU. Pro takovouto verzi se ovšem nepoužije standardní číslování (tedy zvýšení revize), ale za revizi se rozšíří o tečku a další číslo. Případné další NMU už jen zvyšují číslo za tečkou, takže balíček můžeme třeba dostat ve verzi 1.0-1.3, což znamená, že na balíčku byly provedeny tři změny prostřednictvím NMU.

Binární NMU

Pokud je potřeba balíček překompilovat (například se změnilo soname knihovny, kterou program používá) a není potřeba nijak měnit zdrojový balíček, může dojít k binárnímu NMU -- balíček je jen překompilován, ale zdrojový balíček zůstal beze změny. Binární balíček má poté k revizi připojenu indikaci tohoto stavu, a to ve formě +b1. Opět je možné tento proces opakovat a získat tak verzi 2.3-1+b4.

Backporty

V případě, že používáme backportované balíčky, tak by měly mít ještě revizi rozšířenou o indikaci backportu: ~bpo${debian_release}+${build_int}. První backport balíčku v původní verzi 1.0-1 pro Debian 4.0 (etch) tedy bude mít verzi 1.0-1~bpo40+1. Při změnách v backportovaném balíčku se zvyšuje poslední číslice, tilda v revizi zajistí přeinstalování balíčkem z distribuce při aktualizaci, protože původní verze je považována za novější.

Jaké změny hrozí?

Když je seriál na konci, je na čase čtenáře připravit na případné změny, které v dohledné době nastanou (nebo mohou nastat). Tento seznam rozhodně není autoritativní, je jen založen na pozorováních autora a jeho odhadu, takže všechno nakonec může dopadnout úplně jinak :-).

Nejbližší změna se asi bude týkat zdrojových balíčků, protože brzy po vydání Lennyho již pravděpodobně bude povoleno používání verze 3.0 a tedy možnosti použít více tarballů a sadu patchů. Tato změna se ovšem také promítne do Debian Policy spolu s dalšími menšími úpravami (takže do Standards-Version budeme opět psát vyšší číslo).

Strojově zpracovatelný debian/copyright si také získává stále větší oblibu a dnes již u nových balíčků převažuje. Proto je na čase si na jeho používání zvyknout. Tento formát se pravděpodobně také do dalšího vydání stane součástí Debian Policy.

Další změna bude užitečná především pro velké balíčky -- bude možné volitelně balíček komprimovat pomocí lzma. Jedná se sice o podstatně lepší kompresní algoritmus, ale také mnohem náročnější na paměť a výkon, proto nebude použit jako výchozí pro celou distribuci, ale jen pro balíčky, kde se jeho použitím ušetří značné místo a u kterých se dá předpokládat, že uživatel disponuje dostatečně výkonným hardwarem (např. pokud chce někdo provozovat OpenOffice.org, tak se dá předpokládat, že to nebude na počítači s 16 MB paměti).

       

Komentáře

Diskuse byla administrátory uzamčena

[r0]

diky moc za vyborny serial

[Robert Krátký]

Připojuji se, něco takového mi velmi chybělo.

[Pev]

Taky moc děkuji.

Jak za celý seriál tak za tento díl - konečně vím, jak to s těmi divnými verzemi je .

[Michal.P]

Super seriál. Díky!

[zito]

Nedávno jsem tyhle informace vstřebával z Debian Policy Manual, Debian Developer's Reference, Debian New Maintainers' Guide apod. a tohle je výborné intro. I když jsem už základ celkem měl, tak jsem se stejně dozvěděl některé další souvislosti.

Výborná práce - díky!

[belisarivs]

LZMA je IMHo narocne jenom na kompresi. Dekomprese ma byt zase pro zmenu velice nenarocna.

Vim, ze nebyl problem nainstalovat veci v instalatoru NSIS kompiromavanem LZMA a velikem ~ 800 MB na 333 MHz K6.

Ale zkomprimovat to na nem uz neslo.

[Michal Čihař]

Při dekompresi je asi třikrát pomalejší než gzip a potřebuje podstatně víc paměti (u lzma to dost záleží na stupni komprese). Což je rozdíl, který je na embedded zařízeních docela znát a prostě to u většiny věcí nestojí za tu drobnou úsporu místa.

[belisarivs]

http://en.wikipedia.org/wiki/Lzma

Decompression-only code for LZMA generally compiles to around 5kB and the amount of RAM required during decompression is principally determined by the size of the sliding window used during compression. Small code size and relatively low memory overhead, particularly with smaller dictionary lengths, make the LZMA decompression algorithm well-suited to embedded applications.

[Michal Čihař]

Při defaultní kompresi podle man stránky potřebuje lzma 9 MB na dekompresi. To je luxus, který je na systému s 16 MB docela drahý a bez swapu v podstatě nemožný (package manager a ostatní procesy taky něco potřebují).

[belisarivs]

OK. S 16 MB embedded jsem nepocital. Na druhou stranu, je dobry napad na ne cpat Debian? nebudou veci jako OpenWRT lepsi?

[Michal Čihař]

No ono i když přidáme na dvojnásobek, tak na 32MB je těch 9MB pro dekompresi je docela dost. A pořád je pohodlnější mít plnodnotnou distribuci než ořezanou věc typu OpenWRT.

[Pev]

OK. S 16 MB embedded jsem nepocital. Na druhou stranu, je dobry napad na ne cpat Debian? nebudou veci jako OpenWRT lepsi?

U nás v síti je na routerboardu s 59MB (tak to píše free) Debian a jsem za něj moc rád .

Použito bývá víc než polovina...