Evoluce správců balíčků

Každé počítačové zařízení používá nějakou formu softwaru k provádění zamýšlených úkolů. V počátcích softwaru byly produkty přísně testovány na chyby a jiné vady. Zhruba v posledním desetiletí byl software vydáván přes internet se záměrem, aby byly případné chyby opraveny použitím nových verzí softwaru. V některých případech má každá jednotlivá aplikace svůj vlastní aktualizátor. V jiných je ponecháno na uživateli, aby zjistil, jak získat a upgradovat software.

Linux brzy přijal praxi udržování centralizovaného umístění, kde uživatelé mohli najít a nainstalovat software. V tomto článku budu diskutovat o historii instalace softwaru na Linuxu a o tom, jak jsou moderní operační systémy udržovány v aktuálním stavu proti nekonečnému přívalu CVE.

Jak se instaloval software v Linuxu před správou balíčků?

Historicky byl software poskytován buď prostřednictvím FTP nebo mailing listů (tato distribuce se nakonec rozrostla o základní webové stránky). Pouze několik malých souborů obsahovalo instrukce k vytvoření binárního souboru (obvykle v tarfile). Rozbalili byste soubory, přečetli soubor readme a pokud byste měli GCC nebo nějakou jinou formu kompilátoru C, obvykle byste spustili ./configure skript s některým seznamem atributů, jako je cesta k souborům knihovny, umístění pro vytvoření nových binárních souborů atd. Kromě toho configure proces by zkontroloval váš systém na závislosti aplikací. Pokud by chyběly nějaké hlavní požadavky, konfigurační skript by se ukončil a vy byste nemohli pokračovat v instalaci, dokud nebudou splněny všechny závislosti. Pokud byl konfigurační skript úspěšně dokončen, zobrazí se Makefile by byl vytvořen.

Jednou Makefile existoval, budete pak pokračovat spuštěním make příkaz (tento příkaz poskytuje jakýkoli kompilátor, který jste používali). make příkaz má řadu voleb zvaných vytvořit příznaky , které pomáhají optimalizovat výsledné binární soubory pro váš systém. V dřívějších dobách výpočetní techniky to bylo velmi důležité, protože hardware se snažil držet krok s požadavky moderního softwaru. Dnes mohou být možnosti kompilace mnohem obecnější, protože většina hardwaru je více než dostačující pro moderní software.

Nakonec po make byl proces dokončen, budete muset spustit make install (nebo sudo make install ), aby bylo možné software skutečně nainstalovat. Jak si dokážete představit, dělat to pro každý jednotlivý software bylo časově náročné a únavné – nemluvě o tom, že aktualizace softwaru byla komplikovaný a potenciálně velmi obtížný proces.

Co je to balíček?

Pro boj s touto složitostí byly vynalezeny balíčky. Balíčky shromažďují více datových souborů dohromady do jednoho archivního souboru pro snazší přenositelnost a ukládání nebo jednoduše komprimují soubory, aby se zmenšil úložný prostor. Binární soubory obsažené v balíčku jsou předkompilovány podle rozumných výchozích hodnot, které si vývojář vybral. Balíčky také obsahují metadata, jako je název softwaru, popis jeho účelu, číslo verze a seznam závislostí nezbytných pro správné fungování softwaru.

Několik variant Linuxu vytvořilo své vlastní formáty balíčků. Některé z nejčastěji používaných formátů balíčků zahrnují:

.deb:Tento formát balíčku používají Debian, Ubuntu, Linux Mint a několik dalších derivátů. Byl to první typ balíčku, který byl vytvořen.
.rpm:Tento formát balíčku se původně jmenoval Red Hat Package Manager. Používá ho Red Hat, Fedora, SUSE a několik dalších menších distribucí.
.tar.xz:I když se jedná pouze o komprimovaný tarball, tento formát používá Arch Linux.

Přestože samotné balíčky nespravují závislosti přímo, představovaly obrovský krok vpřed ve správě softwaru Linux.

Co je to softwarové úložiště?

Před pár lety, před rozšířením chytrých telefonů, byla myšlenka softwarového úložiště pro mnoho uživatelů těžko uchopitelná, pokud nebyli zapojeni do linuxového ekosystému. Dodnes se zdá, že většina uživatelů Windows je stále pevně připojena k tomu, aby otevřela webový prohlížeč a vyhledávala a instalovala nový software. Ti s chytrými telefony si však na myšlenku softwarového „obchodu“ zvykli. Způsob, jakým uživatelé chytrých telefonů získávají software, a způsob, jakým pracují správci balíčků, nejsou nepodobné. I když došlo k několika pokusům o vytvoření atraktivního uživatelského rozhraní pro softwarová úložiště, velká většina uživatelů Linuxu stále používá k instalaci balíčků příkazový řádek. Úložiště softwaru jsou centralizovaným seznamem veškerého dostupného softwaru pro jakékoli úložiště, pro které byl systém nakonfigurován. Níže je uvedeno několik příkladů hledání konkrétního balíčku v úložišti (všimněte si, že tyto byly kvůli stručnosti zkráceny):

Arch Linux with aurman

user@arch ~ $  aurman -Ss kate

extra/kate 18.04.2-2 (kde-applications kdebase)
    Pokročilý textový editor
aur/kate-root 18.04.0-1 (11, 1.139399)
    Pokročilý textový editor, opravený, aby mohl běžet jako root
aur/kate-git r15288.15d26a7-1 (1, 1e-06)
    Pokročilá komponenta editoru, která se používá v mnoha aplikacích KDE vyžadujících komponentu pro úpravu textu

CentOS 7 pomocí YUM

[user@centos ~]$ yum search kate

kate-devel.x86_64 :Vývojové soubory pro kate
kate-libs.x86_64 :Runtime soubory pro kate
kate -part.x86_64 :Kate kpart plugin

Ubuntu pomocí APT

user@ubuntu ~ $ apt search kate
Řazení... Hotovo
Vyhledávání celého textu... Hotovo

kate/xenial 4:15.12.3-0ubuntu2 amd64 
  výkonný textový editor

kate-data/xenial,xenial 4:4.14.3-0ubuntu4 all
  sdílené datové soubory pro textový editor Kate

kate -dbg/xenial 4:15.12.3-0ubuntu2 amd64
  symboly ladění pro Kate

kate5-data/xenial,xenial 4:15.12.3-0ubuntu2 všechny
  sdílené datové soubory pro textový editor Kate

Kteří jsou nejvýznamnější správci balíčků?

Jak je navrženo ve výše uvedeném výstupu, správci balíčků se používají k interakci se softwarovými repozitáři. Následuje stručný přehled některých nejvýznamnějších správců balíčků.

Správci balíčků podle RPM

Aktualizace systémů založených na RPM, zejména těch založených na technologiích Red Hat, má velmi zajímavou a podrobnou historii. Ve skutečnosti aktuální verze yum (pro podnikové distribuce) a DNF (pro komunitu) kombinují několik projektů s otevřeným zdrojovým kódem, aby poskytovaly svou aktuální funkčnost.

Zpočátku Red Hat používal správce balíčků s názvem RPM (Red Hat Package Manager), který se používá dodnes. Jeho primární použití je však instalace RPM, které máte lokálně, nikoli prohledávání softwarových úložišť. Správce balíčků s názvem up2date byl vytvořen, aby informoval uživatele o aktualizacích balíčků a umožnil jim prohledávat vzdálená úložiště a snadno instalovat závislosti. I když to splnilo svůj účel, někteří členové komunity to považovali za up2date měl některé významné nedostatky.

Aktuální zaklínadlo yum pochází z několika různých komunitních snah. Yellowdog Updater (YUP) byl vyvinut v letech 1999-2001 lidmi z Terra Soft Solutions jako back-end engine pro grafický instalátor Yellow Dog Linuxu. Duke University se líbila myšlenka YUP a rozhodla se ji vylepšit. Vytvořili Yellowdog Updater, Modified (yum), který byl nakonec upraven tak, aby pomohl spravovat univerzitní systémy Red Hat Linux. Yum rostl na popularitě a odhaduje se, že do roku 2005 jej bude používat více než polovina linuxového trhu. Dnes téměř každá distribuce Linuxu, která používá RPM, používá yum pro správu balíčků (až na několik významných výjimek).

Práce s yum

Aby yum mohl stahovat a instalovat balíčky z internetového úložiště, soubory musí být umístěny v /etc/yum.repos.d/ a musí mít příponu .repo . Zde je příklad souboru repo:

[local_base]
name=Base CentOS  (local)
baseurl=http://7-repo.apps.home.local/yum-repo/7/
enabled=1 
gpgcheck=0

Toto je pro jedno z mých místních úložišť, což vysvětluje, proč je kontrola GPG vypnutá. Pokud by byla tato kontrola zapnuta, každý balíček by musel být podepsán kryptografickým klíčem a odpovídající klíč by musel být importován do systému, který přijímá aktualizace. Protože toto úložiště spravuji sám, důvěřuji balíčkům a neobtěžuji se je podepisovat.

Jakmile je soubor úložiště na svém místě, můžete začít instalovat balíčky ze vzdáleného úložiště. Nejzákladnějším příkazem je yum update , která aktualizuje každý aktuálně nainstalovaný balíček. Toto není vyžadovat konkrétní krok k obnovení informací o úložištích; toto se provádí automaticky. Ukázka příkazu je uvedena níže:

[user@centos ~]$ aktualizace sudo yum
Načtené pluginy:Fastmirror, product-id, search-disabled-repos, subscribe-manager
local_base                             | 3,6 kB  00:00:00     
local_epel                             | 2,9 kB  00:00:00     
local_rpm_forge                        | 1,9 kB  00:00:00     
místní_aktualizace                          | 3,4 kB  00:00:00     
spideroak-one-stable                   | 2,9 kB  00:00:00     
zfs                                     | 2,9 kB  00:00:00     
(1/6):local_base/group_gz             | 166 kB  00:00:00     
(2/6):local_updates/primary_db        | 2,7 MB  00:00:00     
(3/6):local_base/primary_db           | 5,9 MB  00:00:00     
(4/6):spideroak-one-stable/primary_db | 12 kB  00:00:00     
(5/6):local_epel/primary_db           | 6,3 MB  00:00:00     
(6/6):zfs/x86_64/primary_db           | 78 kB  00:00:00     
local_rpm_forge/primary_db             | 125 kB  00:00:00     
Určení nejrychlejších zrcadel
Řešení závislostí
--> Spuštění kontroly transakce

Pokud jste si jisti, že chcete, aby yum provedl jakýkoli příkaz bez zastavení pro vstup, můžete zadat -y příznak v příkazu, například yum update -y .

Instalace nového balíčku je stejně snadná. Nejprve vyhledejte název balíčku pomocí yum search :

[user@centos ~]$ yum hledat kate

artwiz-aleczapka-kates-fonts.noarch :Písmo Kates v rodině Artwiz
ghc-highlighting-kate-devel.x86_64 :Vývojové soubory knihovny Haskell highlighting-kate
kate-devel.i686 :Vývojové soubory pro kate
kate-devel.x86_64 :Vývojové soubory pro kate
kate-libs.i686 :Runtime soubory pro kate
kate-libs.x86_64 :Runtime soubory pro kate
kate-part.i686 :Kate kpart plugin

Jakmile budete mít název balíčku, můžete jej jednoduše nainstalovat pomocí sudo yum install kate-devel -y . Pokud jste nainstalovali balíček, který již nepotřebujete, můžete jej odstranit pomocí sudo yum remove kate-devel -y . Ve výchozím nastavení yum odstraní balíček a jeho závislosti.

Mohou nastat situace, kdy neznáte název balíčku, ale znáte název nástroje. Předpokládejme například, že hledáte nástroj updatedb , který vytváří/aktualizuje databázi používanou locate příkaz. Pokus o instalaci updatedb vrátí následující výsledky:

[user@centos ~]$ sudo yum install updatedb
Načtené pluginy:Fastmirror, langpacks
Rychlost načítání zrcadel z hostitelského souboru uloženého v mezipaměti
Žádný balíček updatedb není k dispozici.
Chyba:Nic udělat

Z jakého balíčku nástroj pochází, můžete zjistit spuštěním:

[user@centos ~]$ yum whatprovides *updatedb
Načtené pluginy:Fastmirror, langpacks
Načítání rychlosti zrcadlení z hostitelského souboru uloženého v mezipaměti

bacula-director-5.2.13- 23.1.el7.x86_64 :Soubory Bacula Director
Repo        :local_base
Shodováno s:
Název souboru    :/usr/share/doc/bacula-director-5.2.13/updatedb

mlocate-0.26-8.el7.x86_64 :Nástroj pro vyhledávání souborů podle názvu
Repo        :local_base
Shodováno s:
Název souboru    :/usr/bin/updatedb

Důvod, proč jsem použil hvězdičku * před příkazem je, protože yum whatprovides používá cestu k souboru k vytvoření shody. Protože jsem si nebyl jistý, kde se soubor nachází, použil jsem hvězdičku k označení jakékoli cesty.

Možností yum je samozřejmě mnohem více. Doporučuji vám prohlédnout si manuálovou stránku yum, kde najdete další možnosti.

Dandified Yum (DNF) je novější iterace na yum. Zavedena ve Fedoře 18, dosud nebyla přijata v podnikových distribucích a jako taková se převážně používá ve Fedoře (a derivátech). Jeho použití je téměř úplně stejné jako u yum, ale bylo vytvořeno tak, aby řešilo špatný výkon, nezdokumentovaná API, pomalé/přerušené rozlišení závislostí a občasné vysoké využití paměti. DNF je myšleno jako náhrada za yum, a proto nebudu příkazy opakovat – všude tam, kde byste použili yum , jednoduše nahraďte dnf .

Práce se Zypper

Zypper je další správce balíčků, který má pomoci spravovat RPM. Tento správce balíčků je nejčastěji spojován se SUSE (a openSUSE), ale také jej přijaly MeeGo, Sailfish OS a Tizen. Původně byla představena v roce 2006 a od té doby se neustále opakuje. Není toho mnoho, co jiného, než že se Zypper používá jako back-end pro nástroj pro správu systému YaST a někteří uživatelé jej považují za rychlejší než yum.

Použití Zypperu je velmi podobné jako u yum. Chcete-li vyhledat, aktualizovat, nainstalovat nebo odebrat balíček, jednoduše použijte následující:

vyhledat zypper kate
aktualizace zypper
nainstalovat zypper kate
zypper odebrat kate

Některé velké rozdíly vstupují do hry ve způsobu přidávání repozitářů do systému pomocí zypper . Na rozdíl od výše zmíněných správců balíčků zypper přidává úložiště pomocí samotného správce balíčků. Nejběžnější způsob je přes URL, ale zypper také podporuje import ze souborů repo.

suse:~ # zypper addrepo http://download.videolan.org/pub/vlc/SuSE/15.0 vlc
Přidání úložiště 'vlc' [hotovo]
Úložiště 'vlc' bylo úspěšně přidáno

Povoleno     :Ano
Automatické obnovení:Ne
Kontrola GPG   :Ano
URI         :http://download.videolan.org/pub/vlc/SuSE/15.0
Priorita    :99

Úložiště odstraníte podobným způsobem:

suse:~ # zypper removerepo vlc
Odstranění úložiště 'vlc' ................................... ....[hotovo]
Úložiště 'vlc' bylo odstraněno.

Použijte zypper repos příkaz, abyste viděli, jaký je stav úložišť ve vašem systému:

suse:~ # zypper repos
Priority úložiště jsou bez účinku. Všechna povolená úložiště sdílejí stejnou prioritu.

#  | Přezdívka                     | Jméno                                    | Povoleno | Kontrola GPG | Obnovit
---+---------------------------+-------------- ----------------------------+----------+------------ +--------
 1 | repo-debug                | openSUSE-Leap-15.0-Debug                 | Ne      | ----      | ----   
 2 | repo-debug-non-oss        | openSUSE-Leap-15.0-Debug-Non-Oss         | Ne      | ----      | ----   
 3 | repo-debug-update         | openSUSE-Leap-15.0-Update-Debug         | Ne      | ----      | ----   
 4 | repo-debug-update-non-oss | openSUSE-Leap-15.0-Update-Debug-Non-Oss | Ne      | ----      | ----   
 5 | repo-non-oss              | openSUSE-Leap-15.0-Non-Oss               | Ano     | (p) Ano  | Ano    
 6 | repo-oss                  | openSUSE-Leap-15.0-Oss                   | Ano     | (p) Ano  | Ano

zypper dokonce má podobnou schopnost určit, jaký název balíčku obsahuje soubory nebo binární soubory. Na rozdíl od YUM používá v příkazu pomlčku (ačkoli tato metoda vyhledávání je zastaralá):

localhost:~ # zypper what-provides kate
Příkaz 'co-provides' je nahrazen 'search --provides --match-exact'.
Všechny dostupné možnosti naleznete v části 'help search' .
Načítání dat úložiště...
Čtení nainstalovaných balíčků...

S  | Jméno | Shrnutí              | Zadejte       
---+------+----------------------+----------- -
i+ | Kate | Pokročilý textový editor | aplikace
i  | kate | Pokročilý textový editor | balíček

Stejně jako u YUM a DNF má Zypper mnohem bohatší sadu funkcí, než je zde uvedeno. Podrobnější informace naleznete v oficiální dokumentaci.

Správci balíčků založených na Debianu

Jedna z nejstarších linuxových distribucí v současnosti udržovaných, systém Debianu je velmi podobný systémům založeným na RPM. Používají .deb balíčky, které lze spravovat pomocí nástroje nazvaného dpkg . dpkg je velmi podobný ot./min v tom, že byl navržen pro správu balíčků, které jsou dostupné lokálně. Neřeší žádné závislosti (ačkoli provádí kontrolu závislostí) a nemá žádný spolehlivý způsob interakce se vzdálenými repozitáři. Za účelem zlepšení uživatelské zkušenosti a snadnosti použití zadal projekt Debian projekt s názvem Deity . Toto kódové označení bylo nakonec opuštěno a změněno na Advanced Package Tool (APT).

Vydáno jako testovací sestavení v roce 1998 (předtím, než se objevilo v Debianu 2.1 v roce 1999), mnoho uživatelů považuje APT za jednu z definujících vlastností systémů založených na Debianu. Využívá úložiště podobným způsobem jako systémy založené na RPM, ale namísto jednotlivých .repo soubory, které yum používá, apt historicky používal /etc/apt/sources.list ke správě úložišť. V poslední době také přijímá soubory z /etc/apt/sources.d/ . Podle příkladů ve správcích balíčků založených na RPM máte několik možností, jak dosáhnout stejné věci na distribucích založených na Debianu. Soubory můžete upravovat/vytvářet ručně ve výše uvedených umístěních z terminálu nebo v některých případech můžete použít rozhraní uživatelského rozhraní (například Software & Updates poskytuje Ubuntu et al.). Abychom zajistili stejné zacházení se všemi distribucemi, budu pokrývat pouze možnosti příkazového řádku. Chcete-li přidat úložiště bez přímé úpravy souboru, můžete udělat něco takového:

user@ubuntu:~$ sudo apt-add-repository "deb http://APT.spideroak.com/ubuntu-spideroak-hardy/ release restricted"

Tím se vytvoří spideroakone.list soubor v /etc/apt/sources.list.d . Tyto řádky se samozřejmě mění v závislosti na přidávaném úložišti. Pokud přidáváte osobní archiv balíčků (PPA), můžete to udělat takto:

user@ubuntu:~$ sudo apt-add-repository ppa:gnome-desktop

POZNÁMKA: Debian nativně nepodporuje PPA.

Po přidání úložiště je třeba systémy založené na Debianu upozornit, že existuje nové umístění pro hledání balíčků. To se provádí pomocí apt-get update příkaz:

user@ubuntu:~$ sudo apt-get update
Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [107 kB]
Hit:2 http:/ /APT.spideroak.com/ubuntu-spideroak-hardy vydání InRelease
Hit:3 http://ca.archive.ubuntu.com/ubuntu xenial InRelease
Získat:4 http://ca.archive .ubuntu.com/ubuntu xenial-updates InRelease [109 kB]
Získat:5 http://security.ubuntu.com/ubuntu xenial-security/main Balíčky amd64 [517 kB]
Získat:6 http://security.ubuntu.com/ubuntu xenial-security/main Balíčky i386 [455 kB]
Získat:7 http://security.ubuntu.com/ubuntu xenial-security/main Translation-cs [221 kB]
...

Získáno 6 399 kB za 3 s (2 017 kB/s)
Číst seznamy předběžných balíčků

Nyní, když je nový repozitář přidán a aktualizován, můžete balíček vyhledat pomocí apt-cache příkaz:

user@ubuntu:~$ vyhledávání apt-cache kate
aterm-ml - Afterstep XVT - emulátor VT102 pro systém X window
frescobaldi - editor not Qt4 LilyPond
gitit - Wiki engine podporovaný úložištěm souborů git nebo darcs
jedit – Editor založený na pluginech pro programátory
kate – výkonný textový editor
kate-data – sdílené datové soubory pro textový editor Kate
kate -dbg - symboly ladění pro Kate
katepart - komponenta textového editoru pro vložení

Chcete-li nainstalovat kate , jednoduše spusťte odpovídající instalační příkaz:

user@ubuntu:~$ sudo apt-get install kate

Pro odstranění balíčku použijte apt-get remove :

user@ubuntu:~$ sudo apt-get remove kate

Pokud jde o zjišťování balíčků, APT neposkytuje žádné funkce podobné yum whatprovides . Existuje několik způsobů, jak tyto informace získat, pokud se snažíte zjistit, odkud pochází konkrétní soubor na disku.

Použití dpkg

user@ubuntu:~$ dpkg -S /bin/ls
coreutils:/bin/ls

Pomocí apt-file

user@ubuntu:~$ sudo apt-get install apt-file -y 

user@ubuntu:~$ sudo apt-file update

user@ubuntu:~$ apt-file search kate

Problém s apt-file search je, že na rozdíl od yum whatprovides , je příliš podrobný, pokud neznáte přesnou cestu, a automaticky přidává vyhledávání pomocí zástupných znaků, takže nakonec dostanete výsledky pro cokoli se slovem kate v něm:

kate:/usr/bin/kate
kate:/usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katebacktracebrowserplugin.so
kate:/usr/lib/x86_64- linux-gnu/qt5/plugins/ktexteditor/katebuildplugin.so
kate:/usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katecloseexceptplugin.so
kate:/usr/lib/ x86_64-linux-gnu/qt5/plugins/ktexteditor/katectagsplugin.so

Většina z těchto příkladů používá apt-get . Všimněte si, že většina aktuálních výukových programů pro Ubuntu konkrétně používá apt . Jediný apt příkaz byl navržen tak, aby implementoval pouze nejběžněji používané příkazy v arzenálu APT. Protože funkce je rozdělena mezi apt-get , apt-cache a další příkazy apt snaží se je sjednotit do jediného příkazu. Přidává také některé jemnosti, jako je zbarvení, ukazatele průběhu a další odds and ends. Většinu výše uvedených příkazů lze nahradit příkazem apt , ale ne všechny distribuce založené na Debianu aktuálně využívají podporu bezpečnostních záplat pomocí apt ve výchozím nastavení, takže možná budete muset nainstalovat další balíčky.

Správci balíčků na bázi Arch

Arch Linux používá správce balíčků s názvem pacman. Na rozdíl od .deb nebo .rpm pacman používá tradičnější tarball s LZMA2 komprese (.tar.xz ). To umožňuje, aby balíčky Arch Linux byly mnohem menší než jiné formy komprimovaných archivů (jako je gzip ). Pacman, který byl původně vydán v roce 2002, byl neustále opakován a vylepšován. Jednou z hlavních výhod pacmana je, že podporuje Arch Build System, systém pro sestavování balíčků ze zdroje. Sestavovací systém přijímá soubor nazvaný PKGBUILD, který obsahuje metadata (jako jsou čísla verzí, revize, závislosti atd.) a také skript shellu s požadovanými příznaky pro kompilaci balíčku vyhovujícího požadavkům Arch Linuxu. Výsledné binární soubory jsou pak zabaleny do výše zmíněného .tar.xz soubor pro spotřebu pacmanem.

Tento systém vedl k vytvoření Arch User Repository (AUR), což je komunitně řízené úložiště obsahující soubory PKGBUILD a podporující záplaty nebo skripty. To umožňuje, aby bylo v Archu k dispozici prakticky nekonečné množství softwaru. Zjevnou výhodou tohoto systému je, že pokud si uživatel (nebo správce) přeje zpřístupnit software veřejnosti, nemusí procházet oficiálními kanály, aby jej přijal do hlavních úložišť. Nevýhodou je, že se spoléhá na komunitní kurátorství podobné Docker Hub, balíčkům Snap společnosti Canonical nebo jiným podobným mechanismům. Existuje mnoho správců balíčků specifických pro AUR, které lze použít ke stažení, kompilaci a instalaci ze souborů PKGBUILD v AUR (podíváme se na to později).

Práce s pacmanem a oficiálními repozitáři

Hlavní správce balíčků Archu, pacman, používá příznaky místo příkazových slov jako yum a apt . Například pro hledání balíčku byste použili pacman -Ss . Jako u většiny příkazů v Linuxu můžete najít oba manpage a inline nápovědu. Většina příkazů pro pacman použijte synchronizaci (-S) příznak. Například:

user@arch ~ $ pacman -Ss kate

extra/kate 18.04.2-2 (kde-aplikace kdebase)
    Pokročilý textový editor
extra/libkate 0.4. 1-6 [nainstalovaný]
    Karaoke a textový kodek pro vložení do ogg
extra/libtiger 0.3.4-5 [nainstalovaný]
    Knihovna vykreslování pro streamy Kate pomocí Pango a Cairo
extra/ttf-cheapskate 2.0-12
    Kolekce TTFonts z dustimo.com
community/haskell-cheapskate 0.1.1-100
    Experimentální markdown procesor.

Arch také používá úložiště podobná ostatním správcům balíčků. Ve výše uvedeném výstupu mají výsledky vyhledávání předponu úložiště, ve kterém se nacházejí (extra/ a community/ v tomto případě). Podobně jako u systémů založených na Red Hatu a Debianu se Arch spoléhá na to, že uživatel přidá informace o úložišti do konkrétního souboru. Umístění těchto úložišť je /etc/pacman.conf . Níže uvedený příklad je poměrně blízký skladovému systému. Povolil jsem [multilib] úložiště pro podporu Steam:

[možnosti]
Architektura =auto

Barva
CheckSpace

SigLevel    =Požadovaná databázeVolitelné
LocalFileSigLevel =Volitelné
 
[core]
Zahrnout =/etc/pacman.d/mirrorlist

[extra]
Zahrnout =/etc/pacman.d/mirrorlist
 
[komunita]
Zahrnout =/etc/pacman.d/mirrorlist

[multilib]
Zahrnout =/etc/pacman.d/mirrorlist

V pacman.conf je možné zadat konkrétní URL . Tuto funkci lze použít k zajištění toho, aby všechny balíčky pocházely z určitého okamžiku. Pokud například balíček obsahuje chybu, která vás vážně ovlivňuje, a má několik závislostí, můžete se vrátit zpět ke konkrétnímu bodu v čase přidáním konkrétní adresy URL do pacman.conf a poté spusťte příkazy pro downgrade systému:

[core]
Server=https://archive.archlinux.org/repos/2017/12/22/$repo/os/$arch

Stejně jako systémy založené na Debianu, Arch neaktualizuje informace o svém místním úložišti, dokud mu to neřeknete. Databázi balíčků můžete obnovit zadáním následujícího příkazu:

 user @ oblouk ~ $ sudo pacman -sy 
 
 ::Synchronizace databází balíčků ... 
 jádro 130.2 KIB 851k / s 00:00 [######## ################################################## ] 100 %
 navíc                                                                     1645,5,3       1645,3         1645,3         1645,3         1645,3                                                                   1645.3         1645,3                      #########################] 100%
 komunita                                                      #          # #        # #        # #        # #        # #        # # #        # #        #   2 0 ################################################## ##] 100%
 multilib je aktuální

Jak můžete vidět ve výše uvedeném výstupu, pacman si myslí, že databáze balíčků multilib je aktuální. Pokud si myslíte, že je to nesprávné, můžete vynutit obnovení spuštěním pacman -Syy . Pokud chcete aktualizovat celý systém (kromě balíčků nainstalovaných z AUR), můžete spustit pacman -Syu :

user@arch ~ $ sudo pacman -Syu

::Synchronizace databází balíčků...
 jádro je aktuální
 extra je aktuální
 komunita je aktuální
 multilib je aktuální
::Spouštění úplného upgradu systému...
řešení závislostí...
hledání konfliktních balíčků...

Balíčky (45) ceph-13.2.0-2  ceph-libs-13.2.0-2  debootstrap-1.0.105-1  guile-2.2.4-1  harfbuzz-1.8.2-1  harfbuzz-icu- 1.8.2-1  haskell-aeson-1.3.1.1-20
              haskell-attoparsec-0.13.2.2-24  haskell-tagged-0.8.6-1  imagemagick-7.0.8.2.4-1 -1  lib32-libgusb-0.3.0-1  lib32-systemd-239.0-1
              libgit2-1:0.27.2-1  libinput-1.11.2-1  libmagick-7.0.8.6.6.1 1 -1  libopenshot-0.2.0-1  libopenshot-audio-0.1.6-1  libosinfo-1.2.0-1
              libxfce4util-4.13.2-1  minetest-0.4.17.1-1 mon.1 mi -1  mlt-6.10.0-1  mlt-python-bindings-6.10.0-1  ndctl-61.1-1  netctl-1.17-1
              nodejs-10.6.0 -1  

Celková velikost stahování:     2,66 MiB
Celková instalovaná velikost:  879,15 MiB
Čistá velikost upgradu:     -365,27 MiB

::Pokračujte v instalaci ? [A/n]

Ve scénáři uvedeném výše ohledně downgradu systému můžete vynutit downgrade vydáním pacman -Syyuu . Je důležité si uvědomit, že by se to nemělo brát na lehkou váhu. To by ve většině případů nemělo způsobit problém; existuje však možnost, že downgrade balíčku nebo několika balíčků způsobí kaskádové selhání a ponechá váš systém v nekonzistentním stavu. POUŽÍVEJTE OPATRNĚ!

K instalaci balíčku jednoduše použijte pacman -S kate :

user@arch ~ $ sudo pacman -S kate

řešení závislostí...
hledání konfliktních balíčků...

Balíčky (7) editorconfig -core-c-0.12.2-1  kactivities-5.47.0-1  kparts-5.47.0-1  ktexteditor-5.47.0-2  syntax-highlighting-5.47.0-1  threadweaver-5.47.0-1
             kate-18.04.2-2

Celková velikost stahování:  10,94 MiB
Celková instalovaná velikost: 38,91 MiB

::Pokračovat v instalaci? [A/n]

Pro odstranění balíčku můžete spustit pacman -R kate . Tím se odstraní pouze balíček a nikoli jeho závislosti:

user@arch ~ $ sudo pacman -S kate

kontrola závislostí...

Balíčky (1) kate-18.04.2-2

Celková odstraněná velikost: 20,30 MiB

::Chcete tyto balíčky odstranit? [A/n]

Pokud chcete odstranit závislosti, které nejsou vyžadované jinými balíčky, můžete spustit pacman -Rs:

user@arch ~ $ sudo pacman -Rs kate

kontrola závislostí...

Balíčky (7) editorconfig-core-c-0.12.2-1  aktivity -5.47.0-1  kparts-5.47.0-1  ktexteditor-5.47.0-2  syntax-highlighting-5.47.0-1  threadweaver-5.47.0-1
             kate-18.04.2-2

Total Removed Size: 38.91 MiB

::Do you want to remove these packages? [Y/n]

Pacman, in my opinion, offers the most succinct way of searching for the name of a package for a given utility. As shown above, yum a apt both rely on pathing in order to find useful results. Pacman makes some intelligent guesses as to which package you are most likely looking for:

user@arch ~ $ sudo pacman -Fs updatedb
core/mlocate 0.26.git.20170220-1
    usr/bin/updatedb

user@arch ~ $ sudo pacman -Fs kate
extra/kate 18.04.2-2
    usr/bin/kate

Working with the AUR

There are several popular AUR package manager helpers. Of these, yaourt and pacaur are fairly prolific. However, both projects are listed as discontinued or problematic on the Arch Wiki. For that reason, I will discuss aurman . It works almost exactly like pacman, except it searches the AUR and includes some helpful, albeit potentially dangerous, options. Installing a package from the AUR will initiate use of the package maintainer's build scripts. You will be prompted several times for permission to continue (I have truncated the output for brevity):

aurman -S telegram-desktop-bin
~~ initializing aurman...
~~ the following packages are neither in known repos nor in the aur
...
~~ calculating solutions...

::The following 1 package(s) are getting updated:
   aur/telegram-desktop-bin  1.3.0-1  ->  1.3.9-1

?? Do you want to continue? Y/n:Y

~~ looking for new pkgbuilds and fetching them...
Cloning into 'telegram-desktop-bin'...

remote:Counting objects:301, done.
remote:Compressing objects:100% (152/152), done.
remote:Total 301 (delta 161), reused 286 (delta 147)
Receiving objects:100% (301/301), 76.17 KiB | 639.00 KiB/s, done.
Resolving deltas:100% (161/161), done.
?? Do you want to see the changes of telegram-desktop-bin? N/y:N

[sudo] password for user:

...
==> Leaving fakeroot environment.
==> Finished making:telegram-desktop-bin 1.3.9-1 (Thu 05 Jul 2018 11:22:02 AM EDT)
==> Cleaning up...
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) telegram-desktop-bin-1.3.9-1

Total Installed Size: 88.81 MiB
Net Upgrade Size:      5.33 MiB

::Proceed with installation? [Y/n]

Sometimes you will be prompted for more input, depending on the complexity of the package you are installing. To avoid this tedium, aurman allows you to pass both the --noconfirm and --noedit options. This is equivalent to saying "accept all of the defaults, and trust that the package maintainers scripts will not be malicious." USE THIS OPTION WITH EXTREME CAUTION! While these options are unlikely to break your system on their own, you should never blindly accept someone else's scripts.

Závěr

This article, of course, only scratches the surface of what package managers can do. There are also many other package managers available that I could not cover in this space. Some distributions, such as Ubuntu or Elementary OS, have gone to great lengths to provide a graphical approach to package management.

If you are interested in some of the more advanced functions of package managers, please post your questions or comments below and I would be glad to write a follow-up article.

Appendix

# search for packages
yum search 
dnf search 
zypper search 
apt-cache search 
apt search 
pacman -Ss 

# install packages
yum install 
dnf install 
zypper install 
apt-get install 
apt install 
pacman -S 

# update package database, not required by yum, dnf and zypper
apt-get update
apt update
pacman -Sy

# update all system packages
yum update
dnf update
zypper update
apt-get upgrade
apt upgrade
pacman -Su

# remove an installed package
yum remove 
dnf remove 
apt-get remove 
apt remove 
pacman -R 
pacman -Rs 

# search for the package name containing specific file or folder
yum whatprovides *
dnf whatprovides *
zypper what-provides 
zypper search --provides 
apt-file search 
pacman -Fs