Portál AbcLinuxu, 1. května 2025 22:39
Dvoudílný článek představuje balíčkovací systém, kterým se může pochlubit distribuce Gentoo. V první části je představena filosofie Portage a jsou vyjmenovány výhody a nevýhody daného řešení.
Balíčkovací systém Gentoo je velmi povedený. Přesto se chci záměrně vyhnout porovnávání s jinými distribucemi založenými na rpm nebo apt. Gentoo je prostě jen něco další, trochu jiné... ať si každý udělá srovnávací představu sám.
Distribuce Gentoo Linux je založená téměř výhradně na zdrojových kódech, jedná se o takzvanou source nebo meta-distribuci. Neexistují zde žádné číslované verze distribuce, vývoj je nepřetržitý. To znamená, že pokud cokoli instalujete/aktualizujete, stahují se aktuální zdrojové kódy + záplaty a kompilují se ve vašem PC. Vše je ale dobře zautomatizováno a obsluhuje se to snadněji, než by se mohlo na první pohled zdát. Některé věci jako OpenOffice.org, Java, hry... jsou k dispozici v binární podobě a není nutné je kompilovat. Než se pustíme do podrobností, pokusím se shrnout některé obecné klady a zápory:
Závislosti mezi balíčky při instalaci si řeší systém automaticky, a tak je nemusí řešit a dohledávat uživatel (root). Nainstalovat nový SW do funkčního systému je tedy velmi triviální záležitost i pro začátečníka. A to platí i v případě, že to způsobí spoustu závislostí.
Je možno standardním způsobem ovlivnit závislosti u balíčků. Díky tomu se do systému nedostanou zbytečné, nepotřebné balíčky. Třeba MPlayer lze instalovat s/bez jeho GUI, lze ovlivnit, co bude/nebude podporovat (OSS, ALSA, xv, SDL, Matrox, Gtk2, DirectFB...). Když mu zakážeme např. Gtk, nebude mít závislost na Gtk.
Jedna z často zmiňovaných výhod je, že s Gentoo Linuxem jste stále up-to-date. Ale ono to jde i naopak. Pokud chcete, můžete být konzervativní a jen záplatovat danou verzi programu, když nechcete přecházet na vyšší. Ani v takovém případě by neměly nastat potíže v závislostech (nové vs. staré balíčky) - díky kompilaci až na místě.
Není třeba nic hledat na internetu, balíčkovací systém ví, odkud má co stahovat na základě informací v Portage tree, ten obsahuje řadu mirrorů. Pro stahování je používán wget, umí navázat přerušené spojení. Můžeme i nechat vypsat jen URL na potřebné soubory a stahovat jinde na rychlejším připojení.
Dochází k velmi časté aktualizaci ze strany vývojářů Portage. Nejnovější verze jednotlivých programů jsou svižně zařazeny do Portage tree jako nové ebuildy (ebuildy pro KDE 3.2 byly snad úplně současně se zdrojáky). To však neznamená, že se nám bude systém neustále a nekontrolovaně měnit pod rukama a nutit nás tak používat neověřený nový SW, jak by se mohlo zdát.
Portage tree obsahuje opravdu velké množství programů (přes 6000 balíčků). Včetně těch, které obvykle nebývají součástí distribuce - témata z kde-look.org, nVidia ovladače, Ati ovladače, Flash-plugin, Real Player + kodeky, několikero provedení Javy, několik stovek her - téměř všechny, o kterých vychází na Rootu seriál (America's Army, Flight Gear, Unreal Tournament, Quake, Enemy Territory...). Je k dispozici celá řada jader - jak podle větve (od 2.0 (!) po 2.6), tak i podle obsahu, od vanilkových až po ozáplatované speciály a jádra pro různé architektury (ppc, sparc, ia64...). Portage obsahuje spoustu dalších zajímavých věcí, které se sem nevejdou. Jak jsou v něm roztříděny ebuildy do kategorií a v jakém stavu se momentálně nacházejí, můžete spatřit zde.
Existuje zde možnost přesné optimalizace binárního kódu na daný HW - užití instrukcí MMX, SSE, 3Dnow. Optimalizace pro 386 až po Athlon, AthlonXP, Pentium 4, AMD64... Následkem toho je možné zrychlení o několik procent oproti balíčkům šitým na míru obecné architektuře 386, 586 nebo 686. Celkově je zrychlení spíše jen vedlejší efekt, obecně se tomu někdy přikládá až moc velká váha. Na druhou stranu, za specifických podmínek může být nárůst rychlosti docela citelný.
Pokud máte představu, na co potřebujete nějaký program, ale nevíte který a kde ho hledat, vyplatí se podívat do Portage tree. Užitečná věc je také Kportage (GUI pro KDE), bohužel ne všechny věci v Kportage fungují, jak by měly, a vývoj této šikovné utility asi před 3/4 rokem nějak ustal.
Z určitého pohledu je nevýhodou kompilace až na místě. Zabere to samozřejmě čas a chce to co nejvýkonnější CPU + rychlou velkou RAM. Při trendech výkonů dnešních procesorů to bude čím dál menší problém. Prvotní kompilace, instalace všeho pro desktop zabere třeba i 1-2 dny. To je ale jen jednou na začátku, další udržování systému v aktuálním stavu už je mnohem schůdnější a při aktualizaci nových balíčků jde normálně počítač používat paralelně s tímto automatizovaným procesem. Doporučuji spustit proces aktualizace s nízkou prioritou, pak vás nebude téměř vůbec omezovat při současné jiné práci, která potřebuje výkon. Průměrná pravidelná denní aktualizace mého desktopu zabere odhadem pod 10 minut, vydání nového KDE nebo XFree je jistě na déle. Pokud by se mělo jednat o server, není problém tvořit si binární balíčky na jiném počítači, aby server nebyl zatěžován kompilací, a hotové je pak na server instalovat. Obsah celého serveru můžeme mít uvnitř chrootu na jiném PC (klidně i v jiném Linuxu) pro potřeby ladění, kompilování a jako zálohu.
Některé časy, kompilace + vytvoření binárního balíčku na HW: AthlonXP 2000+, 512 MB RAM:
balíček | čas [minut] |
binutils | 5 |
gcc | 48 |
gimp | 20 |
glibc | 38 |
k3b | 20 |
kdevelop | 55 |
kernel | 18 |
mozilla | 61 |
mplayer | 4 |
qt | 45 |
quanta | 27 |
xfree | 52 |
xmms | 3 |
Je třeba mít připojení k internetu, samozřejmě co nejrychlejší. Při každodenní až týdenní aktualizaci to jde přežít i s GPRS připojením. Čím bude cyklus aktualizace delší, tím budou přenášené objemy zdrojáků větší. Často znamená aktualizace nějakého programu jen stažení záplaty. Zdrojové balíčky lze samozřejmě stahovat i jinde a přenést na počítač, který nemá připojení na internet (nebo jen pomalé).
Výhoda přesné optimalizace binárního kódu se může stát i nevýhodou, pokud si
ušijeme celý systém přesně na AthlonXP a nečekaně bude potřeba provozovat ho
na jiném počítači, kde bude třeba Intel 386 . Vše lze překompilovat na jinou
architekturu, ale nějaký čas to potrvá.
Nová instalace celého systému je pro začátečníka v Linuxu hodně tvrdý oříšek. Není tu žádný průvodce a celý systém si vlastně poskládáte pomocí postupné instalace všeho potřebného. Instalace samotná není nic tak obtížného díky automatickému řešení závislostí. Horší je pro začátečníka následná konfigurace a zprovoznění, to se nedělá pomocí nějakého grafického prostředí, ale textově - nastavení služeb, monitoru, myši, klávesnice, X, xdm... Na webu Gentoo.org je ale velmi podrobná a přehledná dokumentace, jak přesně postupovat.
Další nevýhody vymyslíte za domácí úkol .
Portage je základem celé Gentoo distribuce, je to databáze všeho
"nainstalovatelného". Portage tree je adresářová struktura (/usr/portage/...
) přehledně dělená do skupin obsahujících tisíce balíků - ebuildů.
Ebuild je malý skript, který zařídí stažení, konfiguraci, kompilaci a instalaci
dané verze programu včetně vyřešení závislostí na ostatních ebuildech. Ebuildy
se dělí na ty, které jsou označeny jako nestabilní (tzv. maskované), a ty
ostatní. Kupříkladu pro server Apache momentálně existují následující:
apache-1.3.27-r3.ebuild odmaskován
|
Každý ebuild má svoji webovou stránku, Apache zde
Můžeme se tedy rozhodnout, že se pohodlně povezeme na vlně nejnovějších
stabilních ebuildů pomocí automatické aktualizace celého systému. Pokud
víme, co a proč děláme, je možno používat i ty nejnovější, označené ještě
jako nestabilní, nebo naopak starší verze daného programu. U velmi
čerstvých nestabilních ebuildů se může mimořádně i stát, že selže
kompilace. Pojem nestabilní ebuild ale neznamená ani tak nestabilitu
samotného ebuildu, jako spíš neověřenost verze programu, který zastupuje.
Označení -r1
za číslem verze obvykle značí, že jde o danou verzi
obohacenou o nějakou tu záplatu, -rc1
naopak znamená, že daná verze je ještě neúplná. Jak je vidět, můžeme se držet určité verze a tu jen
záplatovat.
Krom ebuildů obsahuje Portage ještě menší množství class. Class je něco jako hromada ebuildů. Například kde.class obsahuje všechny ebuildy týkající se KDE (kdelibs, kdebase, ...).
Druhý díl již bude ryze praktický. Dozvíte se mimo jiné o parametru USE, který ovlivňuje způsob kompilace. Kromě toho v něm bude množství konkrétních příkladů použití příkazů pro ovládání balíčkovacího systému.
# rc-update add domainname defaultzajisti, ze se po staru systemu nastavi pro stroj domenu, ktera je nastavena /etc/dnsdomainname ale myslim, ze v nekterych pripadech (treba v te welcome hlasce po startu systemu) to nema vliv, protoze (asi-myslim si) domenu hleda z dns pomoci gethostbyname(IP) nekdy to pise domena = "none", kdyz nejsem pripojen do netu
apt-cache search cd console
tak mi to vyhodilo rozumnejsi vysledek nez v Gentoo pri
emerge --search cd console
No, mozna je to mou demenci, ale zda se me, ze to vyhleda bud cd a pak pouze console... Tak nevim, ja chtel cd a console...
P.S: A taky kdyz jsem v ciste instalaci po Stage1 hodil
emerge -p gnupg
tak jsem byl dost hotovej z toho, ze to vypsalo, ze je to zavisly na necem/resp. necem z xfree - ? Bohuzel nemuzu ukazat log pac jsem si ho neulozil :(
P.S.S: Ac byl tenkrat na Root.cz publikovan script na ulozeni url pro stazeni potrebnych baliku na jinem PC a pak kompilaci doma, tak z fore na forum.gentoo.org jsem pochopil, ze nyni staci
emerge -p -f balik > urlkestazeni.log
a bude to... No trochu cucim, ze nektery url jsou tam vicekrat, tak jsem to ani nezkousel, abych nestahoval neco xkrat - ?? Jak to presne je?
Dik Jiri
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
takze ten ebuild asi neni uplne blbej ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.