Svatá trojice vs. balíčkovací systém

12. 12. 2007 | Petr Štrajt

Články - Svatá trojice vs. balíčkovací systém  

V diskuzi se občas objevují dotazy na to, jak si zkompilovat nějaký program. Většinou takové otázky pokládají začátečníci, kteří se o sestavení nějakého programu pokusili, protože jim určitý software chyběl. A první, co našli na stránkách hledaného programu, byla právě "svatá trojice". Přitom chtěného cíle mohli dosáhnout i mnohem méně trnitou cestou.

Pokud zjistíte, že vám chybí nějaký program, který potřebujete ke své práci, zkuste jej nejprve vyhledat pomocí balíčkovacího systému své distribuce, v naprosté většině případů potřebný software naleznete a nainstalujete během několika minut pomocí jednoho či dvou příkazů.

Může se stát, že na první pokus neuspějete (potřebný balíček není v databázi balíčkovacího systému nalezen) - nejčastěji k tomu dochází u různých kodeků sloužících k přehrávání multimediálního obsahu.

Tyto programy bývají šířeny pod nějakou omezující licencí, a proto je nebylo možno přidat do standardních repozitářů. Podrobné informace naleznete v dokumentaci vaší distribuce.

Kdy se tedy kompilace programu vyplatí?

Běžně jsou programy dostupné v balíčkovacích systémech většiny distribucí kompilovány s nějakým průměrným nastavením, které nevyužívá všechny možnosti programu. Pokud máte speciální požadavek, je pro vás sestavení ze zdrojového kódu řešením. Pak skutečně může přijít ke slovu "svatá trojice", což je ve skutečnosti posloupnost tří příkazů, s jejichž pomocí lze většinu zdrojových kódů, které využívají GNU Autotools, připravit ke kompilaci, zkompilovat a nainstalovat:

./configure
make
make install

Ti z vás, kteří mají chuť experimentovat, mohou zkusit své štěstí třeba při kompilaci webového prohlížeče Links. Je to relativně malý program a jeho sestavení by na průměrném stroji nemělo trvat dlouho.

Tenhle šikovný program, který je v základní konfiguraci textový, ale dokáže pracovat i v grafickém rozhraní, které naleznete ve většině distribucí. Chcete-li se dozvědět více, navštivte domácí stránku prohlížeče na adrese links.twibright.com. Informace potřebné ke kompilaci programu.

Když je kompilace tak mocný nástroj, proč ji tedy nepoužívat?

• Instalace balíčku trvá cca. minutu. Kompilace většího programu může trvat několik hodin i den. Podle toho, na jak výkonné sestavě kompilujete.
• Instalujete-li program pomocí balíčkovacího systému, tak vám stačí znát název programu, příkaz pro jeho instalaci, aktualizaci a případně odstranění.
• Naproti tomu, kompilace programu není zrovna triviální, vyžaduje poměrně podrobnou znalost daného systému a často můžete narazit na různé problémy.

Nejčastěji první pokusy o kompilaci programu končí hláškou skriptu ./configure, že chybí nějaká knihovna nebo její vývojová verze.

Co jsou to knihovny a k čemu vlastně jsou?

Knihovna je část programu, která obsahuje funkce potřebné pro výkon nějaké činnosti, například vypsání textu na obrazovku, jak si ukážeme dál.

#include stdio.h
main() { printf("Ahoj svete\n"); }

Účelem programu je vypsat na obrazovku nápis Ahoj světe. Samotné vypsání požadovaného textu na obrazovku zajišťuje funkce printf.

Výhodou funkce je to, že programátor se zabývá pouze tím, co udělat, například vypsat text na obrazovku, a neřeší, jak to udělat, to má na starosti funkce.

Jak se liší vývojářská verze knihovny od běžné

Vývojářské verze knihoven obsahují hlavičkové soubory (obyčejně s příponou .h). Pokud máte nainstalovány tyto knihovny, tak můžete na svém systému kompilovat programy, které ke svému běhu využívají tyto knihovny.

Vývojářské verze knihoven nebývají součástí běžné instalace a právě jejich absence bývá nejčastější příčinou problémů s kompilací.

Další nevýhodou ručně kompilovaných programů je, že si sami musíte ohlídat, zda ve vašem programu nebyla odhalena nějaká bezpečnostní chyba a případně se postarat o její odstranění.

Častým argumentem pro ruční kompilaci nějakého programu bývá, že chcete mít novější verzi nějakého softwaru, než je ta, která je obsažena ve vaší distribuci.

Tuto situaci lze řešit vhodným nastavením zdrojů softwaru. Podrobnější informace o tom, jak to řešit v Debianu, naleznete v manuálu.

Závěr

O správě programů v Linuxu by toho šlo napsat ještě hodně, ale to už přenechám povolanějším. Pokud se mezi těmi, kdo tento zápisek četli, našel alespoň jeden člověk, který se vyhne chybám, které jsem nedávno také udělal, pak splnil svůj účel.

Diskuse k tomuto článku

[lingvistický fašista]

Zkratka "vs" se píše bez tečky, neb ji tvoří první a poslední písmeno slova (tj. versus).

[Prcek]

Kdy se tedy se kompilace programu vyplatí?
kompilovány s nějakém průměrným nastavením
s jejichž pomocí lze (většinu) zdrojových kódů (bud to nedavat do zavorky, nebo prekopat celou vetu)
příkaz pro jeho instalaci aktualizaci (chybi tam carka)
programátor se zabývá pouze tím co udělat (chybi tam carka)
Další nevýhodou ručně kompilovaných programů je, že se si sami musíte ohlídat
která je obsažena ve vaší distribuci (chybi tam tecka)
O správě programů v Linuxu, by toho šlo napsat ještě hodně (prebyva tam carka)

[Robert Krátký]

Omlouvám se, včera jsem byl zjevně dost nepozorný.

[kralyk z abclinuxu]

nn, nepochopil jsi; zkratka 'vs.' znamena 'v souboji s'

[Jan Kundrát (jkt)]

Dalsim dost podstatnym duvodem pro pouzivani balicku jsou automaticke aktualizace (opravy chyb, bezpecnostni problemy,...), kontrola zavislosti a vetsinou take nejaka uroven podpory primo od distribuce.

[Vykook]

A neměl by nadpis znít: "Pekelná trojka, co pohřbila nejeden systém." :D

[mozog]

muzes zduvodnit proc ?

ps: asi 2 roky jsem pouzival Slackware a drvivou vetsinu softwaru jsem si sam rucne kompiloval, dalo to hodne prace, ale pak jsem mel pekne vytunenej desktop

[msk]

Zavislosti, kompatibilita, konzistentnost. Ja som vcera zhodou okolnosti riesil problem, ze sa mi jeden program linkoval s inou verziou kniznice, ako pouzival headery. Predpokladal som totiz, ze odinstalaciou starej verzie pomocou rpm mam po probleme. Ale kedze tam niekto narval este jednu verziu rucne, nasledoval find && rm, find && rm, find && rm a takto dookola 10 min nez som to z toho systemu odparal... Tak asi preto...

[happy barney]

njn, ani do auta sa nevypláca tankovať súčastne aj benzín aj naftu

[Petr Drlik]

Také bych ji nazval pekelna trojka, protože jenom čert ví, jak to funguje. Mě v mandrivě ne.

[strby]

tak pak su asi cert

[Michal Kubeček]

Je to trochu kruté, ale jako dlouholetý uživatel Slackware si to mohu dovolit: tady byla řeč o porovnávání ruční kompilace s využitím package managementu. Na Slackware žádný package management není, tam je jenom hodně vzdálený náznak, takže tam se nemáte o co připravit.

[R]

Ale ano - aj ten jednoduchy system umoznuje zistit, ktory subor patri ku ktoremu baliku, balik odinstalovat alebo upgradovat. Aj automaticky (napr. slapt-get). Obcas nieco kompilujem (kedze baliky nie su na vsetko), ale nakoniec namiesto make install pouzijem checkinstall. Tym spravim balik, ktory sice nie je dokonaly, ale aspon nieco.

[Vykook]

Akorát jsi nakonec použil checkinstall, že? A o tom není řeč :)

[mozog]

kdysi jsem ho zkousel, ale to byla nuda

[Jakub Lucký]

Málo adrenalinu při odinstalaci? ;)

[frEon]

i kdyz se nekdo muze divit, na svem debianu to delam taky tak a zadny problem nemam. rozhodne muj system pohrben neni...

[ivan]

On je ohromny rozdil mezi tim jestli pouzivate autoconf, automace, aclocal, libtool, jako koncovy uzivatel anebo jako vyvojar. Po nekalika letech pouzivani techno nastroju byh si dovolil navrhnout aby se mezi stavy projektu "alha", "beta", "rc0", "testing", "production" pridal a jeste dalsi: "bad joke". Nic vic totiz ten slavny autoconf a teda hlavne libtool neni. Kazdemu kdo to pouziva vrele doporucuji prejit na cmake, scons anebo ant.

[Kyosuke]

Bad joke je doporučit CMake, SCons nebo Ant...bez urážky...

[Käyttäjä 11133]

Můžeš to rozvést?

[Kyosuke]

Až se vzbudím. Teď spím...

[jk]

Uz ses vzhuru? Taky by me zajimalo co mas proti cmake a ant.

[little.owl]

Pridavam se k zajemcum o odpoved. Osobne take povazuji GNU Autoconf za bad joke, i kdyz je to standard.

[zde]

++

[kralyk z abclinuxu]

přejdi na gentoo...

[Rozik]

Jednoduchá odpověď: Zkus si třeba zkompilovat novou verzi openssl a přidej k tomu začátečnickou praxi. Výsledkem bude nefunkční SSH a plno dalšího...

[Ladislav Hagara]

Svatá trojice už dávno není jediný způsob jak instalovat software ze zdrojových kódů. Řada projektů opouští autotools a přechází například na cmake nebo scons. Také záleží na použitém programovacím jazyku. Programy psané v ruby se překládají a instalují pomocí rake, programy v jave pomoci ant.
Jenom bych doplnil, že existují linuxové distribuce založené na zdrojových kódech. V Source Mage se například zmíněný links instaluje příkazem "cast links-twibright". Zdrojové kódy se automaticky stáhnou, následně se případně upraví, přeloží a aplikace se nainstaluje. Uživatel se o zdrojové kódy vůbec nemusí zajímat.
Aktualizace, oprava chyb atd. tak funguje i bez binárních balíčků. Jediné co musí uživatel spustit je "sorcery system-update".
Podobné je to také v jiných linuxových distribucích založených na zdrojových kódech.

[trekker.dk]

Svatá trojice už dávno není jediný způsob jak instalovat software ze zdrojových kódů.

Jj, třeba takový apt-get source, apt-get build-deb a dpkg-buildpackage, to umí věci. Člověk si skoro může udělat hybrid mezi Gentoo a Debianem

[msk]

A co uz taky pbuilder ... :)

[Michal Vyskočil]

programy v jave pomoci ant

V horším případě pomocí mavenu - u antu je jednoduché patchnout properties, nebo build.xml, nebo .ent, když mi vzdoruje, ale maven nade mnou zatím s přehledem vítězí :-|

[Käyttäjä 11133]

A není náhodou v případě, že nám nevyhovuje distribuční balík mnohem lepší vzít zdroják toho distribučního, trošku upravit jeho ./configure a vybuildit? Už jen kvůli budoucím nesplněným závislostem... O věcech typu bezpečnostní aktualizace raději ani nemluvím.

[Aleš Kapica]

Jo, je to lepší, ale to už pak musíš vědět něco o tom jak se dělají balíky

[David Jaša]

Když je děláš jenom pro sebe, tak stačí vědět, že se parametry pro configure nacházejí někde v debian/rules nebo ve .spec souboru a že tyto volby občas vynucují další závislosti.

[msk]

Ano, ale potom este treba vediet, ako ten .spec alebo debian/* vybuildit. Mne napr. trvalo cca mesiac, nez som si prostredie a svoje znalosti pripravil do takeho stavu, ze teraz pripravim a do repository naloadujem balik par prikazmi... Okrem toho taky cdbs to hladanie parametrov pre configure dokaze trosku zkomplikovat, nehovoriac o tom, ze stale viac projektov ( chvala bohu ) opusta autotools a prechadza na nieco modernejsie ( napr cmake ).

[Marelis]

Pokud máte nainstalovaný checkinstall tak není problém ten balíček vytvořit.

./configure

make

checkinstall

[satanatas]

občas to problém je, zvláště pak když to vůbec nefunguje :+)

[pj]

zlatej setup.exe

[David Jaša]

setup.exe dělá standardně stejný bordel jako ta "svatá trojice". :-P

[Filip Jirsák]

Kdepak. Větší.

[David Jaša]

Nj, zapoměl jsem na registry...

[Vinicius]

Bordel vytvoreny svatou trojici rad takhle uklidim:

./configure --prefix=/usr/local

Tam snad patri.

[David Jaša]

Však jo. Ale když je tam těch programů a knihoven přibude, tak to je taky bordel. Částečné řešení je instalovat do /opt, do /usr/local cpát jenom symlinky a ty po změnách přegenerovat. Ale bordel to je i tak.

[Aleš Kapica]

Jak můžete v této souvislosti zmiňovat (a zaměňovat význam) setup.exe to fakt nechápu. Setup.exe je obvykle ekvivalentní tomu co zastává balíčkovací systém, tj. instaluje hotové binárky a nic nekompiluje.

[petr_p]

Záleží, jak definujete balíčkovací systém. Jsou systémy, kde kompilace je obvyklou součástí instalace.

[Petr Drlik]

Nevím, kde a co ma být vše nainstalováno(asi úplně všecko), protože klasická instalace (i když budu podle zastánců trojkombinace "lama") z DVD (2005, 2007 nebo 2008)nenainstaluje automaticky takové programy, které mi umožní, abych se bez problemu pokusil zkompilovat nějaký program. Vždy to vyhodí nějakou chybu. Asi by tyto programy měly být v základní instalaci Mandrivy, protože povětšinou nejsou na internetu všechny balíčky v RPM. Když vidím GZ atd., sklesne mi brada a dávám ruce pryč od stahování.

I když je mandriva velice intuitivní, tady někde "soudruzi udělali chybu", chybí ta třešnička na dortu.

[kotyz]

Je potreba nainstalovat -dev nebo -devel balicky. Nestaci mit napriklad balicek libx, ale je treba mit jeste libx-dev (nebo libx-devel, ruzna distra to pojmenovavaji ruzne) aby slo kompilovat (v tech -dev baliccich sou totiz ty potrebny hlavickovy soubory bez kterych to nepujde). Ono vetsinou kdyz to pri ./configure selze, tak to vypise proc, co chybi a kde se to da stahnout (ne vzdy, ale celkem casto).

[jkl]

Na linuxu se ze zdrojových kódů kompilovalo a instalovalo odjakživa a nevidím v tom žádný zádrhel. Mám spíš pocit, že problémy s instalováním software se vyskytly až s příchodem nejrůznějších "usnadňovacích utilit".

[vogo]

Dělat to takhle můžeš i dál, ale kdo si má pamatovat co, kdy, proč a kam, právě proto jsou ty balíčkovací systémy, které ti právě tohle mají hlídat.

[pavlix]

No... usnadnovaci utility a kompilace jsou dve nezavisle veci.

Muzes rozbalovat binarky a rucne je cpat do systemu, muzes instalovat ze zdrojaku pomoci make install, muzes instalovat binarni balicky a muzes instalovat zdrojovy balicky.

[blatnak]

+2

[vogo]

jsem šťastný, že všechen software mám instalovaný z balíčků, pro software, který nebyl v balíčku, jsem si balíčky vytvořil. Moc rád si ten maglajz se sv trojcí odpustím a to že ji někdo používá je jeho problém, ale při troše snahy si lze všechno sám zabalit na všech distribucích, však jak se asi ty zatracené balíčky dělají? :)

A ještě jedna poznámka, sv trojci používám jen když potřebuji nějaký sw a na počítači, na kterém ho chci, nemám možnost jej nainstalovat skrze balíčkovací systém. V tom případě vhodnou kombinací přepínačů pro ./configure zajistím, aby se mi program sestavil a následně nainstaloval do ~/.usr/.

[Robert Krátký]

Vlákno o překladech, přejímání a dalších věcech souvisejících s očekáváním čtenářů bylo přesunuto do samostatné diskuze, protože bylo pod tímto článkem off-topic. Máte-li zájem v debatě pokračovat, přispívejte prosím do osamostatněné diskuze.

[xsubway]

od doby co pouzivam debian, tak prubeh kompilace ze zdrojovych kodu probiha vetsinou nekterym z techto dvou moznosti:

• apt-build build-source jmeno_programu
• kdyz zdrojovy balik neni k dispozici, tak misto sv. trojice pouzivam: dh_make, a pak fakeroot debian/rules binary

[trekker.dk]

Akorát ta druhá možnost většinou vede na nekorektní balíček (což většinou nevadí, protože pro vlastní použití to pravděpodobně problémy nezpůsobí)

[ondracch]

Možná by neškodilo popsat, jak funguje makefile a podobně.

[MaT]

No nevím, myslím, že v tom článku měly být nějak více zdůrazněné i nevýhody tohoto postupu oproti použití balíčkovacího systému. Jako třeba že se pak takové věci dost blbě odinstalovávají - pokud člověk neví, kde všude se to zahnízdí. Prostě dělá to v systému bordel. Trochu se to tady pak zmiňovalo až v diskusi, ale v té už je toho tolik (a tolik opakujícího se), že to nikdo celé třeba ani číst nebude a pak to důležité, co mělo být rovnou v článku, zapadne.

[Pavel Píša]

Jen bych rád připomněl jednu věc, kterou možná méně zkušení uživatelé nepoužívají, a přitom je snadná a chrání systém proti nechtěnému poničení při použití ./configure make make install Všehny projekty založené na Automake a i na současném CMake podporují proměnnou DESTDIR. Pokud je tedy balík vybuildován pro cílový adresář/prefix /usr /usr/local nebo /opt/jméno_balíku, tak je vždy rozumné volat make install s parametrem DESTDIR

make DESTDIR=/cesta/do/prázdného/adresáře install

V cílovém adresáři se vytvoří kompletní struktura instalovaných souborů a adresářů od cílového rootu včetně prefixů. Je pak možné zkontrolovat, co balík po skopírování na root ("/") přemaže a kam se naskládá. Checkinstall tedy není příliš pro dobře udělané projekty potřeba a jen zavádí další potenciální zdroj chyb. Pozor, různé rádoby moderní vymyšlenosti DESTDIR nezvládají a jsou tedy nebezpečné. Další zásada je buildovat out of source directory

tar -xjf pkgname-x.y.z.tar.gz cd pkgname-x.y.z mkdir _build ../configure --prefix=/opt/pkgname make make DESTDIR=/test-install install

Ale to je již asi mírně složitější pro začátečníky a množství špatně udělaných balíčků toto zacházení nezvládne. Bohužel většina "vylepšení" balíčků pro balíčkovací systémy typu Debianu nepodporuje pořádně build out of source directory a zavádí vlastní nekoncepční řešení takže není možné provést build pro více architektur bez zašpinění rozbalených a quiltovaných zdrojáků.

[Pavel Píša]

Oprava formátování tar -xjf pkgname-x.y.z.tar.gz
cd pkgname-x.y.z
mkdir _build
cd _build
../configure --prefix=/opt/pkgname
make
make DESTDIR=/test-install install


[Michal Kubeček]

tak je vždy rozumné volat make install s parametrem DESTDIR

Přesněji: proměnnou, ne parametrem.