Instalační balíčky: Porovnání verzí

Z Wikiknih
Smazaný obsah Přidaný obsah
Řádek 84: Řádek 84:
= Rozdíl mezi DEB, RPM a TGZ =
= Rozdíl mezi DEB, RPM a TGZ =


Kromě formátu souborů je základní rozdíl mezi systémy správy instalačních balíčků v tom, jakým způsobem provádějí jejich instalaci a odebírání.
Kromě formátu souborů je základní rozdíl mezi systémy správy instalačních balíčků v tom, jakým způsobem provádějí jejich instalaci a odebírání. Balík během tohoto procesu se v systému vyskytuje (nebo může vyskytovat v několika stavech:

# ''Balík je k dispozici, nenainstalován'' : Lze stáhnout informace o závislostech nutných pro instalaci balíku, a před jeho vlastní instalací doplnit chzbějící balíky

# ''Balík je k dispozici, nainstalován, ale nezkonfigurován'' : Balík je stažen na lokální disk, rozbalený do dočasné pozice a čeká na konfiguraci. Teprve po úspěšné konfiguraci jsou přepsány z dočasné pozice do systému.

# ''Balík je nainstalován a zkonfigurován'' : Soubory z balíku jsou zavedeny v systému a konfigurační soubory odpovídajícím způsobem nastaveny

# ''Balík je odinstalován, ovšem konfigurační soubory zůstaly zachovány'' : Během odebrání balíku zůstávají konfigurační soubory zachovány. Tím pádem při aktualizaci (nebo opětné instalaci) systém konfigurační soubory nepřepisuje, ale nabídne více možností, mezi jinými úpravu stávajících.

# ''Balík je kompletně odinstalován'' : Balík je odinstalován včetně konfiguračních souborů

Hlavní rozdíl mezi DEB a RPM systémem je v tom, že DEB zachovává tento systém stavů a zachovává uživateli nad těmito stavy kontrolu. RPM systém spoléhá na erudici autora balíku a provádí automaticky všechno sám, s tím, že úpravu konfiguračních souborů je potom nutné provést pomocí nějakých nástrojů dodatečně.

TGZ systém balíků který používá Slackware se z pohledu výše uvedených stavů příliš neliší od RPM, pouze s tím rozdílem že vůbec neřeší nějaké závislosti, takže kromě níže uvedeného problému. Může nastat ještě jiný, který u RPM či DEB nastane pouze pokud balík nainstalujete natvrdo. A to, že vám nová instalace přepíše soubory, které patří do jiného balíku jinou verzí, která nemusí být kompatibilní.

'''V čem je tedy problém..?'''

Pro mne tedy především v tom, že RPM systém se vás na nic neptá. Buď balík nainstaluje, nebo nenainstaluje. Pokud ho nainstaluje, tak vám převalí soubory nainstalované v systému bez ohledu na to, jestli jsou konfigurační soubory špatné nebo ne. Staré konfiguráky sice RPM nepřepíše (nové uloží s příponou ''rpmnew''), jenže pokud váš systém perfektně neznáte, tak se vám hravě může stát, že vám přestane fungovat zásadní systémová část jen proto, že starý konfigurační soubor obsahuje volbu, která byla u nové verze změněna a nové binárky v systému bez ní nebudou pracovat jak mají.


= Tvorba balíku =
= Tvorba balíku =

Verze z 5. 1. 2006, 09:08

Pro usnadnění správy software v linuxových distribucích byly vyvinuty tzv. balíčkovací systémy

Srovnávací tabulka základních dotazovacích příkazů

Popis RPM DEB
Výpis všech nainstalovaných balíků rpm -qa dpkg -l
Vyhledání balíčku ke kterému patří určitý soubor rpm -q --whatprovides /cesta/k/souboru dpkg -S '/cesta/k/souboru'
Výpis obsahu balíčku rpm -ql <nainstalovaný balíček> dpkg -L <nainstalovaný balíček>
Výpis informací z nenainstalovaného balíčku rpm -qp --info /cesta/k/balíku/něco-1.2.3-i386.rpm dpkg -i /cesta/k/balíku/něco-1.2.3-i386.deb
Výpis obsahu nenainstalovaného balíčku rpm -qpl /cesta/k/balíku/něco-1.2.3-i386.rpm dpkg -c /cesta/k/balíku/něco-1.2.3-i386.deb

Schéma balíků

Instalační balíčky mohou být dvou typů:

  • zdrojové - obsahující zdrojový kód aplikace + soubory obsahující makra, nezbytná pro jeho kompilaci a instalaci
  • binární - obsahující již zkopilované binární soubory a další potřebné soubory + hlavičkové soubory nezbytné pro instalaci

deb

Balíčkovací systém debianu používá pro binární balíčky archívy vytvořené archivačním programem ar , které obsahují vždy dva tarballové archívy. Jeden z nich obsahuje informace o balíku a druhý vlastní binární data, která se při instalaci kopírují do systému. Tyto binární balíčky mají příponu deb.

Pro zdrojové balíčky se žádný extra formát nepoužívá, proto zdrojáky pro debian tvoří vždy 3 soubory.

  1. originální zdrojový balíček, který má příponu orig.tar.gz
  2. soubor se základní informací o balíku s příponou dsc
  3. patch, kterým se originální zdroják podrobí tzv. debianizaci, tj. upraví tak aby z něj bylo možné zkompilovat binární balíček. Tento patch je zkomprimovaný a má příponu diff.gz a u balíků vytvořených primárně pro debian se nemusí vyskytovat.

Některé distribuce (např. Ubuntu) používají pro komprimaci primárně komprimaci bz2, takže analogicky je u souborů přípona gz nahrazena touto příponou, jinak princip je týž. Rekompilovat tyto balíky samozřejmě lze, pouze je třeba do toho někdy zasáhnout a rozbalení a opatchování originálního zdroje provést ručně.

V adresáři pool na serveru můžete ještě čas od času nalézt u instalačních balíků soubor s příponou changes, ten však pro rekompilaci balíku není vůbec nutný. Vzniká při kompilaci binárního balíku a obsahuje kontrolní součty, informace o tom kdo balík rekompiloval a kdy, případně jeho digitální podpis atp.

rpm

RPM systém na rozdíl od DEB systému používá jak pro binární, tak zdrojové balíčky binární formát. Balíček s příponou rpm je binární archív, který je tvořen hlavičkou a vloženým cpio archívem, který obsahuje vlastní instalované soubory - buď archív se zdrojovým kódem a tzv. spec souborem, nebo zkompilované binární soubory vlastní aplikace .

Tento archvív lze z rpm balíku extrahovat pomocí utility rpm2cpio

Podle specifikace je rozhodující pro identifikaci rpm balíčku prvních 8 bajtů.

  • první čtyři bajty (řetězec = edab eedb) tvoří tzv. magické číslo podle kterého program file pozná že jde o RPM balíček
  • druhé dva bajty určují použitou verzi rpm ( řetězec = 0300 )
  • zbývající dva určují zda jde o balíček binární (řetězec = 0000) nebo zdrojový (řetězec = 0001)

další bajty pak nesou informace o architektuře pro níž je balíček určen, digitální podpis, atd..

http://www.rpm.org/max-rpm/index.html

tgz

Nástroje pro správu balíků

deb

Základním nástrojem pro správu deb balíků je dpkg , ovšem časteji používaným, komplexnějším nástrojem je apt

rpm

Základním nástrojem pro správu rpm balíků je rpm , lze však použít i apt pro rpm (původně vyvinutý pro distribuci Conectiva, kterou koupil Mandrake - současná Mandriva), urpmi (nástroj z distribuce Mandriva), yast (nástroj z distribuce SuSE), smart, či yum (nástroj z distribuce Fedora)

tgz

Rozdíl mezi DEB, RPM a TGZ

Kromě formátu souborů je základní rozdíl mezi systémy správy instalačních balíčků v tom, jakým způsobem provádějí jejich instalaci a odebírání. Balík během tohoto procesu se v systému vyskytuje (nebo může vyskytovat v několika stavech:

  1. Balík je k dispozici, nenainstalován : Lze stáhnout informace o závislostech nutných pro instalaci balíku, a před jeho vlastní instalací doplnit chzbějící balíky
  1. Balík je k dispozici, nainstalován, ale nezkonfigurován : Balík je stažen na lokální disk, rozbalený do dočasné pozice a čeká na konfiguraci. Teprve po úspěšné konfiguraci jsou přepsány z dočasné pozice do systému.
  1. Balík je nainstalován a zkonfigurován : Soubory z balíku jsou zavedeny v systému a konfigurační soubory odpovídajícím způsobem nastaveny
  1. Balík je odinstalován, ovšem konfigurační soubory zůstaly zachovány : Během odebrání balíku zůstávají konfigurační soubory zachovány. Tím pádem při aktualizaci (nebo opětné instalaci) systém konfigurační soubory nepřepisuje, ale nabídne více možností, mezi jinými úpravu stávajících.
  1. Balík je kompletně odinstalován : Balík je odinstalován včetně konfiguračních souborů

Hlavní rozdíl mezi DEB a RPM systémem je v tom, že DEB zachovává tento systém stavů a zachovává uživateli nad těmito stavy kontrolu. RPM systém spoléhá na erudici autora balíku a provádí automaticky všechno sám, s tím, že úpravu konfiguračních souborů je potom nutné provést pomocí nějakých nástrojů dodatečně.

TGZ systém balíků který používá Slackware se z pohledu výše uvedených stavů příliš neliší od RPM, pouze s tím rozdílem že vůbec neřeší nějaké závislosti, takže kromě níže uvedeného problému. Může nastat ještě jiný, který u RPM či DEB nastane pouze pokud balík nainstalujete natvrdo. A to, že vám nová instalace přepíše soubory, které patří do jiného balíku jinou verzí, která nemusí být kompatibilní.

V čem je tedy problém..?

Pro mne tedy především v tom, že RPM systém se vás na nic neptá. Buď balík nainstaluje, nebo nenainstaluje. Pokud ho nainstaluje, tak vám převalí soubory nainstalované v systému bez ohledu na to, jestli jsou konfigurační soubory špatné nebo ne. Staré konfiguráky sice RPM nepřepíše (nové uloží s příponou rpmnew), jenže pokud váš systém perfektně neznáte, tak se vám hravě může stát, že vám přestane fungovat zásadní systémová část jen proto, že starý konfigurační soubor obsahuje volbu, která byla u nové verze změněna a nové binárky v systému bez ní nebudou pracovat jak mají.

Tvorba balíku

Existuje několik utilit, které usnadňují tvorbu instalačních balíčků - checkinstall , resp. jejich vzájemnou konverzi - alien

deb

Kompilace zdrojového balíčku z distribuce

Relativně nejsnazší cestou jak vytvořit vlastní binární balíček je použití zdrojového balíčku dodávaného v distribuci. Postup se pokusím rozdělit do několika kroků:

  • Nejprve jako root musíte doinstalovat balíky nutné pro splnění požadovaných závislostí:
#apt-get build-dep <kompilovaná aplikace>
  • Potom už jako uživatel stáhnete a rozbalíte zdroj aplikace, co máte v úmyslu kompilovat. Že musíte mít nastavený v souboru /etc/apt/sources.list také zdroje ke zdrojákům , snad není nutno příliš zdůrazňovat.
#apt-get source <kompilovaná aplikace>
APT stáhne příslušný zdrojový balíček a rozbalí do aktuální pozice.
  • Skočíte do vytvořeného podadresáře a spustíte proces sestavení balíku příkazem
#dpkg-buildpackage -rfakeroot
Tento příkaz má řadu dalších parametrů, jimiž můžete kompilaci balíku řídit. Kupř. mě odmítl kompilaci provést, dokud jsem neurčil parametrem -m budoucího vlastníka (sebe)
  • Pokud je proces sestavení přerušen, je nutné analyzovat příčinu a pokusit se ji odstranit. Nejčastější příčiny..
  • nesplněné závislosti (viz první bod)
  • zastaralá verze některého z nezbytných programů (nejprve zkusit aktualizovat systém, popřípadě rekompilovat nejprve vyžadovaný program)
  • Proběhne-li kompilace v pořádku, naleznete v původním umístění zkompilovaný binární balíček, který můžete přes dpkg nainstalovat.


Balíček můžete také kompilovat ihned po stažení, pokud přidáte při stahování zdroje parametr -b Pak je však nutné spouštět příkaz jako root

Vytvoření vlastního balíčku ze zdrojového kódu

V distribucích založených na debianu je k dispozici balíček dh-make, který obsahuje skript, který je velkou pomocí při tzv. "debianizaci" zdrojového kódu aplikace. Příkaz dh_make, spuštěný v kořenu adresáře se zdrojovými kódy aplikace vytvoří základní soubory, nezbytné pro vytvoření balíčku. Ty pak stačí pouze modifikovat, podle specifických potřeb kompilovaného software.

Jde především o tyto soubory:

control - ve kterém se udávají závislosti, a další informační údaje

rules - který obsahuje vlastní scénář kompilace balíku (sem zadáváte parametry pro konfigurační skript, patche atp.)

rpm

tgz

Odkazy

deb

http://www.root.cz/clanky/balickovaci-system-debian-gnu-linux-apt/

http://www.root.cz/clanky/balickovaci-system-debian-gnu-linux-seznam-zdroju/

http://www.root.cz/clanky/balickovaci-system-debian-gnulinux-apt-get-2/

http://www.root.cz/clanky/balickovaci-system-debian-gnu-linux-source-build-dep/

http://www.root.cz/clanky/balickovaci-system-debian-gnu-linux-apt-cache/

http://www.root.cz/clanky/balickovaci-system-debian-gnu-linux-apt-file/

rpm

Rukověť baliče RPM - I (Úvod)

Rukověť baliče RPM - II (Prostředí)

Rukověť baliče RPM - III (Struktura spec souboru)

Rukověť baliče RPM - IV (Fáze balení)