Balíčky pro Debian - 10 (speciální balíčky)

9. 10. 2008 | Michal Čihař | Návody | 3817×

Balíček pro jednoduchý program už umíme, dnes se podíváme na některé speciální balíčky, které budou potřebovat trochu zvláštní péče (knihovny, moduly pro Python, práce s databázemi).

Obsah

• Sdílené knihovny
• Moduly a skripty v Pythonu
• Démoni
• Používání databáze

Sdílené knihovny

Jak se rozdělují soubory do balíčků knihoven, již bylo popsáno v díle věnujícím se programu dh_install (instalace souborů), takže už víme, že při balení knihovny budeme mít nejméně dva balíčky - libbar0 a libbar-dev. Kromě nich je ještě dobré vytvořit balíček s ladicími informacemi libbar0-dbg (k tomu nám pomůže dh_strip popsaný dříve), a pokud knihovna obsahuje i větší množství dat, můžeme je od ní oddělit do balíčku libbar-common.

Balíčků nám tedy může vzniknout mnoho a určitě by mezi nimi měly být nějaké závislosti, abychom vždy dostali funkční balíček. Pro vývojový balíček budeme potřebovat knihovnu ve stejné verzi, proto musí záviset na libbar0 (= ${binary:Version}). Balíček s daty je sice samostatně celkem k ničemu, ale i přes to si ho někdo může chtít nainstalovat bez knihovny (například může chtít použít data v něm obsažená v jiném programu), a proto použijeme jen doporučení (Suggests) na libbar0. Vlastní knihovna oproti tomu data určitě potřebovat bude, proto zde závislost musíme zavést. Podle charakteru dat musíme vybrat, jak striktně budeme vyžadovat stejnou verzi. Obvykle se ovšem používá závislost na stejné nebo novější verzi, tedy libbar-common (>= ${source:Version}). Poslední je balíček s ladicími symboly, a ten samozřejmě nemá smysl s jinou verzí knihovny, než ze které byl vytvořen - libbar0 (= ${binary:Version}).

Ostatní problémy, se kterými se můžete setkat při vytváření balíčků knihovny, se již nijak neliší od jiných balíčků, ale na správné závislosti je třeba si dávat pozor.

Moduly a skripty v Pythonu

Moduly pro Python by v systému měly být k dispozici pokud možno pro všechny nainstalované verze Pythonu a měly by být zkompilované do byte-kódu. To je asi hlavní požadavek, který dal vzniknout dvěma programům pro přípravu pythonních balíčků - python-central a python-support. Oba v současné době nabízejí srovnatelné možnosti a jediný důvod, proč budu dále popisovat python-central, je ten, že jej používám; python-support by posloužil stejně dobře. Mezi autory těchto programů sice panuje menší nevraživost, ale to nevadí tomu, aby vám kterýkoliv z nich dobře posloužil.

Oba dva přesunou moduly do svého adresáře a při instalaci je zkompilují do byte-kódu a nějakým způsobem je předhodí Pythonu. Toto samozřejmě funguje jen pro moduly, které jsou napsané jen v Pythonu a neobsahují žádnou kompilovanou část. Tyto kompilované je potřeba při vytváření balíčku zkompilovat pro všechny podporované verze Pythonu. Program pyversions nám prozradí, které verze jsou v současné době podporované, a v debian/rules se pak podle toho musíme zařídit a použít všechny verze Pythonu, takže kompilace bude vypadat například následovně:

PYVERSIONS=$(shell pyversions -r)
...
build-stamp:
    dh_testdir
    # Build normal modules
    set -e; \
    for python in $(PYVERSIONS) ; do \
        $$python setup.py build ; \
    done

Dále ve finální fázi vytváření balíčku musíme spustit pomocný skript dh\_pycentral, který nám dopočítá některé substituční proměnné pro debian/control a vygeneruje skriptíky pro správné nainstalování modulů v systému.

V souboru debian/control musíme kromě nových závislostí (python-all-dev a python-central) uvést několik nových polí:

Source: python-bar
...
XS-Python-Version: all

Package: python-bar
...
Provides: ${python:Provides}
XB-Python-Version: ${python:Versions}
Depends: ${shlibs:Depends}, ${python:Depends}

Pole XS-Python-Version u zdrojového balíčku určuje, pro které verze Pythonu balíček je možné balíček zkompilovat. Obvykle je to možné pro všechny a můžeme tedy použít hodnotu all. U binárního balíčku se pak do XB-Python-Version doplní, pro které verze Pythonu byl balíček zkompilován, a v závislostech používáme další nově vygenerované proměnné.

To by pro základní moduly pro Python mělo stačit, podrobnější popis Problematiky naleznete na wiki.

Démoni

Poslední případ balíčku, který si dnes popíšeme, jsou démoni. Tedy spíš cokoliv, co se spouští při startu systému a má spouštěcí skript. Nejdůležitější část je vytvořit tento spouštěcí skript; vlastní instalaci a zařazení do startovací sekvence již zařídí dh_installinit. Spouštěcí skript umístíme do zdrojového balíčku jako debian/binární-balíček.init.

Pokud démon má nějaké parametry z příkazové řádky, je vhodné dát uživateli možnost je změnit v konfiguračním souboru umístěném do /etc/default/. Tento adresář obsahuje části skriptů, které jsou obvykle ve spouštěcím skriptu použity právě pro specifikaci parametrů spouštěných služeb. Pokud ve zdrojovém balíčku budeme mít soubor debian/binární-balíček.default, nainstaluje ho dh_installinit jako /etc/default/binární-balíček a pak ho můžeme ze spouštěcího skriptu použít.

Jak by tedy spouštěcí skript měl vypadat? Protože Debian dodržuje zásady LSB, měl by obsahovat standardní hlavičku s informace o službě, kterou poskytuje. Pokud jsme vytvářeli balíček programem dh_make, ten nám vytvořil ukázkový spouštěcí skript jako debian/init.d.ex a tento nám může dobře posloužit jako základ pro další práci.

Používání databáze

Pokud program používá databázi, máme také možnost tyto databázi vytvářet v rámci skriptíků spouštěných při instalaci a vytvořit konfigurační soubor s přístupovými parametry do databáze. Veškerou tuto činnost má na starosti balíček dbconfig-common. Ten v současné době podporuje MySQL, PostgreSQL a SQLite a umožní základní nastavení databáze, vytvoření uživatelů a na případné dotazy se ptá uživatele pomocí debconfu.

Kompletní návod k použití zde vypisovat nebudu, ale v zásadě je použití jednoduché a ukážeme si ho na příkladu pro MySQL (pro jiné databáze stačí změnit mysql v následujících příkladech za odpovídající text). Přidáme skript pro vytváření potřebných tabulek do balíčku jako /usr/share/dbconfig-common/data/jméno_balíčku/install/mysql a ve skriptíkách přidat volání dbconfig-common. Do jméno_balíčku.config přijde jen konfigurace:

. /usr/share/debconf/confmodule
if [ -f /usr/share/dbconfig-common/dpkg/config.mysql ]; then
        . /usr/share/dbconfig-common/dpkg/config.mysql
        dbc_go jméno_balíčku $@
fi

V jméno_balíčku.postinst pak můžeme i třeba vygenerovat konfigurační soubor v PHP (dbconfig-common nabízí i jiné formáty):

. /usr/share/dbconfig-common/dpkg/postinst.mysql
dbc_generate_include_owner=www-data
dbc_generate_include=php:/etc/jméno_balíčku/config-db.php
dbc_go jméno_balíčku $@

Pak už jen stačí zařídit, aby se vygenerovaný soubor nějak použil v aplikaci a vše by mělo automaticky fungovat. Podotýkám, že toto je nejjednodušší použití, ale je možné dělat i mnohem složitější operace, včetně aktualizace struktury databáze při aktualizaci na novou verzi.

       

Komentáře

[Jirka P]

Překlep: s/libbar-bar/libbar-dbg/

MMCH, ta závislost (Suggests:) mezi daty a knihovnou je standardní praxe? V archivu jsem na toto téma našel všehochuť, od Depends: libbar0 přes Recommends a Suggests až po Conflicts: libbar0 (< x). Dá se nějak zařídit, pokud jsou data a "knihovna" v jiném balíčku (případ některých her), aby data šla nainstalovat samostatně, ale do testingu šly ty balíčky pouze v kompatibilních verzích (a nestalo se tedy, že nová data vyhodí starou binárku)?

[Jirka P]

Ještě ty -dbg balíčky: nestálo by za to (nedá se zařídit) mít i -dbg balíčky se soname? Když mi segfaultne program, který ještě nepřešel na libbar1 (používá libbar0), je mi libbar-dbg pro libbar1 platný jak mrtvýmu zimník. Jaký jsou pravidla pro mazání z testingu, umožňovaly by to?

[Michal Čihař]

No v článku to tak bylo zamýšleno . Je to čistě na tom, kdo balíčky vytváří a na tom co považuje za pravděpodobnější (ostatně to samé platí pro -dev balíčky).

[Michal Čihař]

Spíš s/libbar0-bar/libbar0-dbg/ ne?

Knihovna obvykle musí mít data, takže závislost z knihovny na data musí být Depends. Opačně to není nutné, protože data je třeba možná použít i v něčem jiném (at už to je jakkoliv pravděpodobné). A ani to není dobré, protože by vzniknul kruh závislostí a to může způsobit problémy při instalaci. To jestli tam bude Suggests nebo Recommends, je víceméně na správci. Konflikt může být na místě pokud nová verze dat nějak rozbíjí knihovnu, ale spíš bych to řešil závislostí knihovny na správné verzi dat.

No pokud jsou data ve stejném zdrojovém balíčku, tak se nemůže stát, že budou migrovat samostatně. Jinak je potřeba mít závislosti tak, aby samostatná migrace nemohla nastat.

[Jirka P]

Opačně to není nutné, protože data je třeba možná použít i v něčem jiném (at už to je jakkoliv pravděpodobné).

Tady bych byl opatrný, pokud maintainer myslí, že libbar0-data je možno použít i jinak než v libbar0, měl by zároveň garantovat nějakou funkčnost balíku libbar0-data. Což ho omezuje v takových akcích jako smazání půlky souborů v nějaké revizi.

A ani to není dobré, protože by vzniknul kruh závislostí a to může způsobit problémy při instalaci.

Dost by mě zajímalo, čím a jaké problémy to způsobuje. Vím, že o tom čas od času jistý B.A. vyvolá na -⁠devel flame, ale ty jeho zdůvodnění jsou tak trochu divný. Že cokoli rozbije dist-upgrade nic neznamená, dist-upgrade je rozbitý sám o sobě. Že to zvětšuje složitost vyhodnocování a splňování závislostí prostě není pravda. Problémy s pořadím spouštění instalačních skriptů sice můžou být, ale ne pokud jeden z těch balíků ty skripty nemá atd.

Jinak je potřeba mít závislosti tak, aby samostatná migrace nemohla nastat.

No jo, ale jak to udělat?

[Michal Čihař]

Dost by mě zajímalo, čím a jaké problémy to způsobuje. Vím, že o tom čas od času jistý B.A. vyvolá na -⁠devel flame, ale ty jeho zdůvodnění jsou tak trochu divný. Že cokoli rozbije dist-upgrade nic neznamená, dist-upgrade je rozbitý sám o sobě. Že to zvětšuje složitost vyhodnocování a splňování závislostí prostě není pravda. Problémy s pořadím spouštění instalačních skriptů sice můžou být, ale ne pokud jeden z těch balíků ty skripty nemá atd.

Spíš bych ten problém formuloval opačně: jaký je dobrý důvod k vytvoření kruhové závislosti? V mnoha případech sice problém nezpůsobí, ale to není důvod jich mít v distribuci stovky a komplikovat tak jakýkoliv upgrade.

Jinak je potřeba mít závislosti tak, aby samostatná migrace nemohla nastat.

No jo, ale jak to udělat?

Při migraci se kontroluje jestli se nerozbijí závislosti jiných balíčků, takže pokud potřebuju nějakou verzi dat, stačí to dát do závislostí, např.:

Package: program
Depends: data (>= 1.0), data (<< 1.1)