Handbook:Parts/Working/Portage/cs

Portage vás vítá
Portage je jednou s nejpozoruhodnějších inovací Gentoo na poli správy softwaru. Se svojí vysokou flexibilitou a obrovským množstvím funkcí je často pokládána za nejlepší nástroj pro správu softwaru dostupný pro Linux.

Portage je kompletně napsána v Pythonu a Bashi a je tak pro uživatele naprosto transparentní, jelikož se jedná o skriptovací jazyky.

Většina uživatelů bude s Portage pracovat prostřednictvím nástroje. Cílem této kapitoly není duplikovat informace dostupné v manuálové stránce emerge. Pro vyčerpávající přehled voleb emerge se prosím podívejte na manuálovou stránku:

Ebuildy
Pokud dokumentace Gentoo hovoří o balíčcích, má tím na mysli softwarové tituly dostupné uživatelům Gentoo skrze strom Portage. Ten obsahuje sbírku ebuildů, souborů, které obsahují veškeré informace, které Portage potřebuje k nakládání s programy (instalaci, vyhledávání, dotazování,...). Ve výchozím stavu se soubory ebuildů nacházejí v.

Kdykoli je Portage dán požadavek na provedení akce, která se týká softwaru, použije ebuildy v systému, jako výchozí bod. Proto je třeba pravidelně aktualizovat ebuildy v systému, tak, aby Portage věděl o novém softwaru, bezpečnostních aktualizacích atd.

Aktualizace stromu Portage
Strom Portage se aktualizuje příkazem, utilitou pro rychlý přírůstkový přenos souborů. Aktualizace je opravdu jednoduchá, jelikož příkaz poskytuje rozhraní pro.

Někdy se však vyskytnou omezení daná firewallem, která znemožní příkazu navázat spojení se zrcadly. V takovém případě aktualizujte strom Portage přes každodenně generovaný snímek stromu Portage. Nástroj automaticky stáhne a nainstaluje poslední snímek do systému:

Další výhodou použití je to, že umožňuje správci, aby stáhl pouze snímky stromu Portage, které jsou podepsány GPG klíčem týmu Gentoo release engineering. Více informací o tomto tématu lze najít na stránce Vlastnosti Portage v sekcizískání ověřených snímků stromu Portage.

Vyhledání softwaru
Způsobů jak vyhledávat software ve stromu Portage je mnoho. Jednou z cest je využití samotného programu. V základu příkaz vrátí názvy balíčků, jejichž název odpovídá (buď úplně, nebo i částečně) danému vyhledávacímu dotazu.

Například k vyhledání všech balíčků, které mají v názvu "pdf":

Pokud chcete prohledávat také popisy, použijte volbu  (nebo také  ):

Všimněte si, že výstup vrací mnoho informací. jednotlivá pole jsou jasně označena, tudíž nebudeme více vysvětlovat jejich význam:

Instalace softwaru
Pokud jsme žádaný software našli, dělí nás od jeho instalace již jen jeden příkaz. Pro nainstalování gnumeric je to například:

Jelikož mnoho aplikací závisí jedna na druhé, jakýkoli pokus o instalaci určitého softwaru může vést také k instalaci několik závislostí. Nebojte, Portage si se závislostmi poradí. Abyste zjistili, co Portage nainstaluje, použijte volbu. Například:

Během instalování balíčku Portage stáhne z internetu nezbytný zdrojový kód (je-li to potřeba) a uloží jej (ve výchozím stavu) do. Potom jej rozbalí, zkompiluje a balíček nainstaluje. Chcete-li dát Portage instrukce, aby došlo pouze ke střžení zdrojových kódů bez jejich instalace, předejte příkazu emerge volbu :

Nalezení dokumentace nainstalovaných balíčků
Spousta balíčků obsahuje vlastní dokumentaci. Někdy se to, zda bude dokumentace balíčku nainstalována nebo ne, určuje pomocí přepínače USE. Ke zjištění, zda je přepínač USE balíčkem používán, použijte příkaz.

Nejlepší je zapínat přepínač USE doc pro každý balíček zvlášť pomocí souboru, tak aby byla instalována dokumentace jen pro balíčky, u kterých to chceme. Více informací si můžete přečíst v kapitole o přepínačích USE.

Po instalaci balíčku se jeho dokumentace nachází většinou v podadresáři pojmenovaném po balíčku v adresáři. je také možné nechat si vypsat všechny nainstalovaného soubory s pomocí nástroje, který je součástí balíčku.

A more sure way to list installed documentation files is to use 's  option. is used to query Portage's database and comes as part of the package:

The  option can be used with other rules to view the install locations for many other types of files. Additional functionality can be reviewed in 's man page:.

Odstranění softwaru
K odstranění softwaru ze systému použijte příkaz. Tím dáte Portage instrukce, aby odstranila soubory nainstalované daným balíčkem ze systému. Vyjímkou jsou konfigurační soubory aplikace, "pokud" byly uživatelem změněny. Ponechání konfiguračních souborů umožňuje uživateli, aby mohl pokračovat v práci s balíčkem bez nutnosti rekonfigurace, pokud by byl později znovu nainstalován.

Pokud je balíček odstraněn ze systému, závislosti tohoto balíčku, které byly automaticky nainstalovány spolu s ním, jsou stále zachovány v systému. Aby Portage nalezl všechny závislosti, které mohou být nyní odstraněny, použijte funkci emerge, která je popsána později.

Aktualizace systému
Abyste udrželi systém ve formě (nemluvě o instalaci nejnovějších bezpečnostních aktualizací), je třeba aktualizovat pravidelně systém. Jelikož Portage kontroluje pouze ebuildy ve stromu Portage, první věcí, kterou musíte udělat, je aktualizace stromu Portage. Jakmile je strom Portage aktualizován, může být systém aktualizován pomocí. V následujícím příkladu používáme také volbu, který říká Portage, aby zobrazil seznam balíčků, které chce aktualizovat a vyžádal potvrzení:

Portage po vyhledá novější verze instalovaných aplikací. Nicméně zkontroluje pouze verze aplikací, které byly explicitně nainstalovány (aplikace obsažené v - nebude zevrubně kontrolovat jejich závislosti. Chcete-li aktualizovat zároveň i závislosti, použijte volbu  :

To stále nezahrnuje všechny balíčky: některé balíčky v systému jsou potřebné během kompilace a sestavování balíčků, ale jakmile je balíček nainstalován, tyt závislosti již nejsou k ničemu potřeba. Portage jim říká "build dependencies" (závislosti sestavení). K jejich zahrnutí do aktualizačního cyklu přidejte volbu :

Protože bezpečnostní aktualizace se často dějí i v balíčcích, které jste neinstalovali do systému přímo (ale byly vtaženy do systému jako závislosti jiných programů), doporučuje se čas od času tento příkaz spustit.

Pokud jste v systému změnili nastavení USE, doporučuje se také přidat volbu. Portage pak ověří, zda změna vyžaduje instalaci nových balíčků nebo překompilování již existujících:

Metabalíčky
Některé balíčky ve stromu Portage nemají žádný reálný obsah, ale používají se k instalaci sestav balíčků. Například balíček nainstaluje do systému kompletní prostředí KDE tím, že vtáhne rozličné balíčky související s KDE jako závislosti.

Spuštění k odstranění takového balíku ze systému nebude mít žádný efekt, jelikož závislosti zůstanou v systému.

Portage obsahuje funkci k odstranění osiřelých závislostí, avšak jelikož je dostupnost softwaru dynamicky proměnná, je nejdříve nejdůležitější provést celkovou aktualizaci systému, včetně změn přepínačů USE. Potom lze spustit příkaz k odstranění osiřelých závislostí. Jakmile je toto dokončeno, může být nutné znovu sestavit aplikace, které byly dynamicky propojené k nyní již odstraněnému softwaru, ale nadále ho již nepotřebují. Tato funkce byla do Portage nedávno přidána.

O vše se postarají následující tři příkazy:

Program je součástí balíčku ; nezapomeňte si jej nainstalovat:

Licence
Počínaje Portage verze 2.1.7 je možné schválit nebo naopak odmítnout instalaci software na základě jeho licence. Všechny balíčky ve stromu obsahují ve svém ebuildu údaj o licenci. Příkaz zobrazí licenci balíčku.

Ve výchozím stavu Portage povoluje všechny licence s výjimkou "End User License Agreements" (Dohoda o licenci uzavřená s koncovým uživatelem, pozn. překl.), které vyžadují přečtení a podpis dohody o akceptaci.

Proměnná, která ovládá povolené licence, se nazývá ACCEPT_LICENSE a může být nastavena v. V následujícím příkladu je ukázána výchozí hodnota:

S tímto nastavením nelze instalovat balíčky, které vyžadují během instalace potvrzení EULA. Balíčky bez EULy nainstalovat půjdou.

Proměnnou ACCEPT_LICENSE je možné nastavit globálně v, nebo zvlášť specifikovat pro každý balíček v.

Například k povolené licence k balíčku, přidejte do  následující:

Tím umožníte instalaci trucryptu ve verzích s licencí, ale ne ve verzích s licencí.

.

Skupiny licencí se v proměnné ACCEPT_LICENSE označují znakem. Nejběžnějším požadovaným nastavením je umožnit instalaci pouze svobodnému softwaru a dokumentaci. Abychom toho dosáhli, odstraníme všechny v současnosti povolené licence (pomocí ) a pak povolíme pouze licence ve skupině FREE následujícím způsobem:

Note that this setting will also accept non-free software and documentation.

Terminology
As stated before, Portage is extremely powerful and supports many features that other software management tools lack. To understand this, we explain a few aspects of Portage without going into too much detail.

With Portage different versions of a single package can coexist on a system. While other distributions tend to name their package to those versions (like freetype and freetype2) Portage uses a technology called SLOTs. An ebuild declares a certain SLOT for its version. Ebuilds with different SLOTs can coexist on the same system. For instance, the freetype package has ebuilds with SLOT="1" and SLOT="2".

There are also packages that provide the same functionality but are implemented differently. For instance, metalogd, sysklogd, and syslog-ng are all system loggers. Applications that rely on the availability of "a system logger" cannot depend on, for instance, metalogd, as the other system loggers are as good a choice as any. Portage allows for virtuals: each system logger is listed as an "exclusive" dependency of the logging service in the logger virtual package of the virtual category, so that applications can depend on the package. When installed, the package will pull in the first logging package mentioned in the package, unless a logging package was already installed (in which case the virtual is satisfied).

Software in the Gentoo repository can reside in different branches. By default the system only accepts packages that Gentoo deems stable. Most new software titles, when committed, are added to the testing branch, meaning more testing needs to be done before it is marked as stable. Although the ebuilds for those software are in the Gentoo repository, Portage will not update them before they are placed in the stable branch.

Some software is only available for a few architectures. Or the software doesn't work on the other architectures, or it needs more testing, or the developer that committed the software to the Gentoo repository is unable to verify if the package works on different architectures.

Each Gentoo installation also adheres to a certain profile which contains, amongst other information, the list of packages that are required for a system to function normally.

Blocked packages
Ebuilds contain specific fields that inform Portage about its dependencies. There are two possible dependencies: build dependencies, declared in the DEPEND variable and run-time dependencies, likewise declared in RDEPEND. When one of these dependencies explicitly marks a package or virtual as being not compatible, it triggers a blockage.

While recent versions of Portage are smart enough to work around minor blockages without user intervention, occasionally such blockages need to be resolved manually.

To fix a blockage, users can choose to not install the package or unmerge the conflicting package first. In the given example, one can opt not to install postfix or to remove ssmtp first.

Sometimes there are also blocking packages with specific atoms, such as. In this case, updating to a more recent version of the blocking package could remove the block.

It is also possible that two packages that are yet to be installed are blocking each other. In this rare case, try to find out why both would need to be installed. In most cases it is sufficient to do with one of the packages alone. If not, please file a bug on Gentoo's bugtracking system.

Masked packages
When trying to install a package that isn't available for the system, this masking error occurs. Users should try installing a different application that is available for the system or wait until the package is marked as available. There is always a reason why a package is masked:

Necessary USE flag changes
The error message might also be displayed as follows, if  isn't set:

Such warning or error occurs when a package is requested for installation which not only depends on another package, but also requires that that package is built with a particular USE flag (or set of USE flags). In the given example, the package app-text/feelings needs to be built with USE="test", but this USE flag is not set on the system.

To resolve this, either add the requested USE flag to the global USE flags in, or set it for the specific package in.

Missing dependencies
The application to install depends on another package that is not available for the system. Please check Bugzilla if the issue is known and if not, please report it. Unless the system is configured to mix branches, this should not occur and is therefore a bug.

Ambiguous ebuild name
The application that is selected for installation has a name that corresponds with more than one package. Supply the category name as well to resolve this. Portage will inform the user about possible matches to choose from.

Circular dependencies
Two (or more) packages to install depend on each other and can therefore not be installed. This is most likely a bug in one of the packages in the Gentoo repository. Please re-sync after a while and try again. It might also be beneficial to check Bugzilla to see if the issue is known and if not, report it.

Fetch failed
Portage was unable to download the sources for the given application and will try to continue installing the other applications (if applicable). This failure can be due to a mirror that has not synchronized correctly or because the ebuild points to an incorrect location. The server where the sources reside can also be down for some reason.

Retry after one hour to see if the issue still persists.

System profile protection
The user has asked to remove a package that is part of the system's core packages. It is listed in the profile as required and should therefore not be removed from the system.

Digest verification failure
This is a sign that something is wrong with the Gentoo repository - often, caused by a mistake made when committing an ebuild to the Gentoo ebuild repository.

When the digest verification fails, do not try to re-digest the package personally. Running will not fix the problem; it quite possibly could make it worse.

Instead, wait an hour or two for the repository to settle down. It is likely that the error was noticed right away, but it can take a little time for the fix to trickle down the rsync mirrors. Check Bugzilla and see if anyone has reported the problem yet or ask around on (IRC). If not, go ahead and file a bug for the broken ebuild.

Once the bug has been fixed, re-sync the Gentoo ebuild repository to pick up the fixed digest.