Ogni dispositivo computerizzato utilizza una qualche forma di software per eseguire i compiti previsti. Agli albori del software, i prodotti venivano sottoposti a severi test per rilevare bug e altri difetti. Negli ultimi dieci anni circa, il software è stato rilasciato tramite Internet con l'intento di correggere eventuali bug applicando nuove versioni del software. In alcuni casi, ogni singola applicazione dispone del proprio programma di aggiornamento. In altri, spetta all'utente capire come ottenere e aggiornare il software.
Linux ha adottato presto la pratica di mantenere una posizione centralizzata in cui gli utenti potevano trovare e installare il software. In questo articolo parlerò della storia dell'installazione di software su Linux e di come i moderni sistemi operativi vengono tenuti aggiornati contro il torrente infinito di CVE.
Come veniva installato il software su Linux prima dei gestori di pacchetti?
Storicamente, il software veniva fornito tramite FTP o mailing list (alla fine questa distribuzione sarebbe cresciuta fino a includere siti Web di base). Solo alcuni piccoli file contenevano le istruzioni per creare un binario (normalmente in un file tar). Decomprimere i file, leggere il readme e, purché tu abbia GCC o qualche altra forma di compilatore C, in genere eseguiresti un ./configure script con un elenco di attributi, come il percorso dei file della libreria, il percorso per creare nuovi file binari e così via. Inoltre, configure processo verificherebbe il tuo sistema per le dipendenze dell'applicazione. Se mancavano dei requisiti principali, lo script di configurazione si chiudeva e non è possibile procedere con l'installazione finché tutte le dipendenze non sono state soddisfatte. Se lo script di configurazione è stato completato correttamente, viene visualizzato un Makefile verrebbe creato.
Una volta un Makefile esisteva, dovresti quindi procedere con l'esecuzione di make comando (questo comando è fornito dal compilatore che stavi utilizzando). Il make comando ha una serie di opzioni chiamate crea flag , che aiutano a ottimizzare i binari risultanti per il tuo sistema. All'inizio dell'informatica, questo era molto importante perché l'hardware faticava a tenere il passo con le moderne richieste di software. Oggi, le opzioni di compilazione possono essere molto più generiche poiché la maggior parte dell'hardware è più che adeguata per il software moderno.
Infine, dopo il make era stato completato, dovresti eseguire make install (o sudo make install ) per installare effettivamente il software. Come puoi immaginare, eseguire questa operazione per ogni singolo software è stato noioso e dispendioso in termini di tempo, per non parlare del fatto che l'aggiornamento del software era un processo complicato e potenzialmente molto complicato.
Cos'è un pacchetto?
I pacchetti sono stati inventati per combattere questa complessità. I pacchetti raccolgono più file di dati insieme in un unico file di archivio per facilitare la portabilità e l'archiviazione, o semplicemente comprimono i file per ridurre lo spazio di archiviazione. I binari inclusi in un pacchetto sono precompilati in base alle sane impostazioni predefinite scelte dallo sviluppatore. I pacchetti contengono anche metadati, come il nome del software, una descrizione del suo scopo, un numero di versione e un elenco di dipendenze necessarie per il corretto funzionamento del software.
Diverse versioni di Linux hanno creato i propri formati di pacchetto. Alcuni dei formati di pacchetto più comunemente usati includono:
- .deb:questo formato di pacchetto è utilizzato da Debian, Ubuntu, Linux Mint e molti altri derivati. È stato il primo tipo di pacchetto ad essere creato.
- .rpm:Questo formato di pacchetto era originariamente chiamato Red Hat Package Manager. È usato da Red Hat, Fedora, SUSE e molte altre distribuzioni minori.
- .tar.xz:Sebbene sia solo un tarball compresso, questo è il formato utilizzato da Arch Linux.
Sebbene i pacchetti stessi non gestiscano direttamente le dipendenze, hanno rappresentato un enorme passo avanti nella gestione del software Linux.
Cos'è un repository software?
Alcuni anni fa, prima della proliferazione degli smartphone, l'idea di un repository software era difficile da afferrare per molti utenti se non erano coinvolti nell'ecosistema Linux. Ad oggi, la maggior parte degli utenti Windows sembra essere ancora cablata per aprire un browser Web per cercare e installare nuovo software. Tuttavia, quelli con gli smartphone si sono abituati all'idea di un "negozio" di software. Il modo in cui gli utenti di smartphone ottengono il software e il modo in cui funzionano i gestori di pacchetti non sono dissimili. Sebbene ci siano stati diversi tentativi di creare un'interfaccia utente attraente per i repository di software, la stragrande maggioranza degli utenti Linux utilizza ancora la riga di comando per installare i pacchetti. I repository software sono un elenco centralizzato di tutto il software disponibile per qualsiasi repository che il sistema è stato configurato per utilizzare. Di seguito sono riportati alcuni esempi di ricerca in un repository per un pacchetto specifico (notare che questi sono stati troncati per brevità):
Arch Linux con aurman
user@arch ~ $ aurman -Ss kate
extra/kate 18.04.2-2 (kde-applications kdebase)
Advanced Text Editor
aur/kate-root 18.04.0-1 (11, 1.139399)
Advanced Text Editor, patched to be able to run as root
aur/kate-git r15288.15d26a7-1 (1, 1e-06)
An advanced editor component which is used in numerous KDE applications requiring a text editing component
CentOS 7 con YUM
[user@centos ~]$ yum search kate
kate-devel.x86_64 : Development files for kate
kate-libs.x86_64 : Runtime files for kate
kate-part.x86_64 : Kate kpart plugin
Ubuntu usando APT
user@ubuntu ~ $ apt search kate
Sorting... Done
Full Text Search... Done
kate/xenial 4:15.12.3-0ubuntu2 amd64
powerful text editor
kate-data/xenial,xenial 4:4.14.3-0ubuntu4 all
shared data files for Kate text editor
kate-dbg/xenial 4:15.12.3-0ubuntu2 amd64
debugging symbols for Kate
kate5-data/xenial,xenial 4:15.12.3-0ubuntu2 all
shared data files for Kate text editor
Quali sono i gestori di pacchetti più importanti?
Come suggerito nell'output precedente, i gestori di pacchetti vengono utilizzati per interagire con i repository software. Quella che segue è una breve panoramica di alcuni dei più importanti gestori di pacchetti.
Gestione pacchetti basati su RPM
L'aggiornamento dei sistemi basati su RPM, in particolare quelli basati sulle tecnologie Red Hat, ha una storia molto interessante e dettagliata. In effetti, le versioni attuali di yum (per le distribuzioni aziendali) e DNF (per la comunità) combinano diversi progetti open source per fornire le loro attuali funzionalità.
Inizialmente, Red Hat utilizzava un gestore di pacchetti chiamato RPM (Red Hat Package Manager), che è ancora in uso oggi. Tuttavia, il suo utilizzo principale è installare gli RPM, che hai localmente, non per cercare repository software. Il gestore di pacchetti denominato up2date è stato creato per informare gli utenti degli aggiornamenti ai pacchetti e consentire loro di cercare repository remoti e installare facilmente le dipendenze. Sebbene servisse al suo scopo, alcuni membri della comunità hanno ritenuto che up2date presentava alcune carenze significative.
L'attuale incantesimo di yum è venuto da diversi sforzi della comunità. Yellowdog Updater (YUP) è stato sviluppato nel 1999-2001 da persone di Terra Soft Solutions come motore back-end per un programma di installazione grafico di Yellow Dog Linux. Alla Duke University è piaciuta l'idea di YUP e ha deciso di migliorarla. Hanno creato Yellowdog Updater, Modified (yum) che alla fine è stato adattato per aiutare a gestire i sistemi Red Hat Linux dell'università. Yum è cresciuto in popolarità e nel 2005 si stima che fosse utilizzato da più della metà del mercato Linux. Oggi, quasi tutte le distribuzioni di Linux che utilizzano RPM utilizzano yum per la gestione dei pacchetti (con alcune eccezioni degne di nota).
Lavorare con yum
Affinché yum scarichi e installi pacchetti da un repository Internet, i file devono trovarsi in /etc/yum.repos.d/ e devono avere l'estensione .repo . Ecco un esempio di file repository:
[local_base]
name=Base CentOS (local)
baseurl=http://7-repo.apps.home.local/yum-repo/7/
enabled=1
gpgcheck=0
Questo è per uno dei miei repository locali, il che spiega perché il controllo GPG è disattivato. Se questo controllo fosse attivo, ogni pacchetto dovrebbe essere firmato con una chiave crittografica e una chiave corrispondente dovrebbe essere importata nel sistema che riceve gli aggiornamenti. Poiché gestisco personalmente questo repository, mi fido dei pacchetti e non mi preoccupo di firmarli.
Una volta che un file di repository è a posto, puoi iniziare a installare i pacchetti dal repository remoto. Il comando più semplice è yum update , che aggiornerà ogni pacchetto attualmente installato. Questo non richiedere un passaggio specifico per aggiornare le informazioni sui repository; questo viene fatto automaticamente. Di seguito è mostrato un esempio del comando:
[user@centos ~]$ sudo yum update
Loaded plugins: fastestmirror, product-id, search-disabled-repos, subscription-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
local_updates | 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
Determining fastest mirrors
Resolving Dependencies
--> Running transaction check
Se sei sicuro di volere che yum esegua qualsiasi comando senza fermarti per l'input, puoi inserire il -y flag nel comando, come yum update -y .
Installare un nuovo pacchetto è altrettanto facile. Per prima cosa, cerca il nome del pacchetto con yum search :
[user@centos ~]$ yum search kate
artwiz-aleczapka-kates-fonts.noarch : Kates font in Artwiz family
ghc-highlighting-kate-devel.x86_64 : Haskell highlighting-kate library development files
kate-devel.i686 : Development files for kate
kate-devel.x86_64 : Development files for kate
kate-libs.i686 : Runtime files for kate
kate-libs.x86_64 : Runtime files for kate
kate-part.i686 : Kate kpart plugin
Una volta che hai il nome del pacchetto, puoi semplicemente installarlo con sudo yum install kate-devel -y . Se hai installato un pacchetto che non ti serve più, puoi rimuoverlo con sudo yum remove kate-devel -y . Per impostazione predefinita, yum rimuoverà il pacchetto più le sue dipendenze.
Ci possono essere momenti in cui non si conosce il nome del pacchetto, ma si conosce il nome dell'utilità. Ad esempio, supponiamo che tu stia cercando l'utilità updatedb , che crea/aggiorna il database utilizzato da locate comando. Tentativo di installare updatedb restituisce i seguenti risultati:
[user@centos ~]$ sudo yum install updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
No package updatedb available.
Error: Nothing to do
Puoi scoprire da quale pacchetto proviene l'utilità eseguendo:
[user@centos ~]$ yum whatprovides *updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
bacula-director-5.2.13-23.1.el7.x86_64 : Bacula Director files
Repo : local_base
Matched from:
Filename : /usr/share/doc/bacula-director-5.2.13/updatedb
mlocate-0.26-8.el7.x86_64 : An utility for finding files by name
Repo : local_base
Matched from:
Filename : /usr/bin/updatedb
Il motivo per cui ho usato un asterisco * davanti al comando è perché yum whatprovides utilizza il percorso del file per creare una corrispondenza. Poiché non ero sicuro di dove si trovasse il file, ho usato un asterisco per indicare qualsiasi percorso.
Ci sono, ovviamente, molte altre opzioni disponibili per yum. Ti incoraggio a visualizzare la pagina man di yum per ulteriori opzioni.
Dandified Yum (DNF) è una nuova iterazione su yum. Introdotto in Fedora 18, non è stato ancora adottato nelle distribuzioni enterprise, e come tale è utilizzato prevalentemente in Fedora (e derivati). Il suo utilizzo è quasi esattamente lo stesso di yum, ma è stato creato per affrontare scarse prestazioni, API non documentate, risoluzione delle dipendenze lenta/non funzionante e uso occasionale di memoria elevata. DNF è inteso come un sostituto drop-in di yum, e quindi non ripeterò i comandi, ovunque tu voglia usare yum , sostituisci semplicemente dnf .
Lavorare con Zypper
Zypper è un altro gestore di pacchetti pensato per aiutare a gestire gli RPM. Questo gestore di pacchetti è più comunemente associato a SUSE (e openSUSE), ma è stato adottato anche da MeeGo, Sailfish OS e Tizen. È stato originariamente introdotto nel 2006 e da allora è stato ripetuto. Non c'è molto da dire a parte il fatto che Zypper viene utilizzato come back-end per lo strumento di amministrazione del sistema YaST e alcuni utenti lo trovano più veloce di yum.
L'utilizzo di Zypper è molto simile a quello di yum. Per cercare, aggiornare, installare o rimuovere un pacchetto, utilizza semplicemente quanto segue:
zypper search kate
zypper update
zypper install kate
zypper remove kate
Alcune importanti differenze entrano in gioco nel modo in cui i repository vengono aggiunti al sistema con zypper . A differenza dei gestori di pacchetti discussi sopra, zypper aggiunge repository utilizzando lo stesso gestore di pacchetti. Il modo più comune è tramite un URL, ma zypper supporta anche l'importazione da file repository.
suse:~ # zypper addrepo http://download.videolan.org/pub/vlc/SuSE/15.0 vlc
Adding repository 'vlc' [done]
Repository 'vlc' successfully added
Enabled : Yes
Autorefresh : No
GPG Check : Yes
URI : http://download.videolan.org/pub/vlc/SuSE/15.0
Priority : 99
Rimuovi i repository in modo simile:
suse:~ # zypper removerepo vlc
Removing repository 'vlc' ...................................[done]
Repository 'vlc' has been removed.
Usa i zypper repos comando per vedere qual è lo stato dei repository sul tuo sistema:
suse:~ # zypper repos
Repository priorities are without effect. All enabled repositories share the same priority.
# | Alias | Name | Enabled | GPG Check | Refresh
---+---------------------------+-----------------------------------------+---------+-----------+--------
1 | repo-debug | openSUSE-Leap-15.0-Debug | No | ---- | ----
2 | repo-debug-non-oss | openSUSE-Leap-15.0-Debug-Non-Oss | No | ---- | ----
3 | repo-debug-update | openSUSE-Leap-15.0-Update-Debug | No | ---- | ----
4 | repo-debug-update-non-oss | openSUSE-Leap-15.0-Update-Debug-Non-Oss | No | ---- | ----
5 | repo-non-oss | openSUSE-Leap-15.0-Non-Oss | Yes | ( p) Yes | Yes
6 | repo-oss | openSUSE-Leap-15.0-Oss | Yes | ( p) Yes | Yes
zypper ha anche una capacità simile di determinare quale nome di pacchetto contiene file o binari. A differenza di YUM, utilizza un trattino nel comando (sebbene questo metodo di ricerca sia deprecato):
localhost:~ # zypper what-provides kate
Command 'what-provides' is replaced by 'search --provides --match-exact'.
See 'help search' for all available options.
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+------+----------------------+------------
i+ | Kate | Advanced Text Editor | application
i | kate | Advanced Text Editor | package
Come con YUM e DNF, Zypper ha un set di funzionalità molto più ricco di quello trattato qui. Consulta la documentazione ufficiale per informazioni più approfondite.
Gestori di pacchetti basati su Debian
Una delle più vecchie distribuzioni Linux attualmente mantenute, il sistema di Debian è molto simile ai sistemi basati su RPM. Usano .deb pacchetti, che possono essere gestiti da uno strumento chiamato dpkg . dpkg è molto simile a rpm in quanto è stato progettato per gestire i pacchetti disponibili localmente. Non esegue la risoluzione delle dipendenze (sebbene esegua il controllo delle dipendenze) e non ha un modo affidabile per interagire con i repository remoti. Per migliorare l'esperienza dell'utente e la facilità d'uso, il progetto Debian ha commissionato un progetto chiamato Deity . Questo nome in codice è stato infine abbandonato e cambiato in Advanced Package Tool (APT).
Rilasciato come build di test nel 1998 (prima di fare la sua comparsa in Debian 2.1 nel 1999), molti utenti considerano APT una delle caratteristiche distintive dei sistemi basati su Debian. Fa uso di repository in modo simile ai sistemi basati su RPM, ma invece di singoli .repo file che yum utilizza, apt ha usato storicamente /etc/apt/sources.list per gestire i repository. Più recentemente, importa anche file da /etc/apt/sources.d/ . Seguendo gli esempi nei gestori di pacchetti basati su RPM, per ottenere la stessa cosa su distribuzioni basate su Debian hai alcune opzioni. Puoi modificare/creare i file manualmente nelle suddette posizioni dal terminale o, in alcuni casi, puoi utilizzare un front-end dell'interfaccia utente (come Software & Updates fornito da Ubuntu et al.). Per fornire lo stesso trattamento a tutte le distribuzioni, tratterò solo le opzioni della riga di comando. Per aggiungere un repository senza modificare direttamente un file, puoi fare qualcosa del genere:
user@ubuntu:~$ sudo apt-add-repository "deb http://APT.spideroak.com/ubuntu-spideroak-hardy/ release restricted"
Questo creerà un spideroakone.list file in /etc/apt/sources.list.d . Ovviamente, queste righe cambiano a seconda del repository che viene aggiunto. Se stai aggiungendo un PPA (Personal Package Archive), puoi farlo:
user@ubuntu:~$ sudo apt-add-repository ppa:gnome-desktopNOTA: Debian non supporta i PPA in modo nativo.
Dopo che un repository è stato aggiunto, i sistemi basati su Debian devono essere informati che esiste una nuova posizione in cui cercare i pacchetti. Questo viene fatto tramite l'apt-get update comando:
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 release InRelease
Hit:3 http://ca.archive.ubuntu.com/ubuntu xenial InRelease
Get:4 http://ca.archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]
Get:5 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [517 kB]
Get:6 http://security.ubuntu.com/ubuntu xenial-security/main i386 Packages [455 kB]
Get:7 http://security.ubuntu.com/ubuntu xenial-security/main Translation-en [221 kB]
...
Fetched 6,399 kB in 3s (2,017 kB/s)
Reading package lists... Done
Ora che il nuovo repository è stato aggiunto e aggiornato, puoi cercare un pacchetto utilizzando apt-cache comando:
user@ubuntu:~$ apt-cache search kate
aterm-ml - Afterstep XVT - a VT102 emulator for the X window system
frescobaldi - Qt4 LilyPond sheet music editor
gitit - Wiki engine backed by a git or darcs filestore
jedit - Plugin-based editor for programmers
kate - powerful text editor
kate-data - shared data files for Kate text editor
kate-dbg - debugging symbols for Kate
katepart - embeddable text editor component
Per installare kate , esegui semplicemente il comando di installazione corrispondente:
user@ubuntu:~$ sudo apt-get install kate
Per rimuovere un pacchetto, usa apt-get remove :
user@ubuntu:~$ sudo apt-get remove kate
Quando si tratta di scoprire pacchetti, APT non fornisce alcuna funzionalità simile a yum whatprovides . Ci sono alcuni modi per ottenere queste informazioni se stai cercando di trovare la provenienza di un file specifico su disco.
Utilizzo di dpkg
user@ubuntu:~$ dpkg -S /bin/ls
coreutils: /bin/ls
Utilizzo di apt-file
user@ubuntu:~$ sudo apt-get install apt-file -y
user@ubuntu:~$ sudo apt-file update
user@ubuntu:~$ apt-file search kate
Il problema con apt-file search è che, a differenza di yum whatprovides , è eccessivamente dettagliato a meno che tu non conosca il percorso esatto e aggiunge automaticamente una ricerca con caratteri jolly in modo da ottenere risultati per qualsiasi cosa con la parola kate in esso:
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
La maggior parte di questi esempi ha utilizzato apt-get . Nota che la maggior parte degli attuali tutorial per Ubuntu in particolare hanno iniziato a usare semplicemente apt . Il singolo apt command è stato progettato per implementare solo i comandi più comunemente usati nell'arsenale APT. Poiché la funzionalità è divisa tra apt-get , apt-cache e altri comandi, apt cerca di unificarli in un unico comando. Aggiunge anche alcune sottigliezze come la colorazione, le barre di avanzamento e altre cianfrusaglie. La maggior parte dei comandi sopra indicati possono essere sostituiti con apt , ma non tutte le distribuzioni basate su Debian attualmente ricevono il supporto per le patch di sicurezza utilizzando apt per impostazione predefinita, quindi potrebbe essere necessario installare pacchetti aggiuntivi.
Gestori di pacchetti basati su Arch
Arch Linux utilizza un gestore di pacchetti chiamato pacman. A differenza di .deb o .rpm file, pacman usa un tarball più tradizionale con LZMA2 compressione (.tar.xz ). Ciò consente ai pacchetti Arch Linux di essere molto più piccoli rispetto ad altre forme di archivi compressi (come gzip ). Rilasciato inizialmente nel 2002, pacman è stato costantemente aggiornato e migliorato. Uno dei principali vantaggi di pacman è che supporta Arch Build System, un sistema per la creazione di pacchetti dal sorgente. Il sistema di build ingerisce un file chiamato PKGBUILD, che contiene metadati (come numeri di versione, revisioni, dipendenze, ecc.) così come uno script di shell con i flag richiesti per compilare un pacchetto conforme ai requisiti di Arch Linux. I binari risultanti vengono quindi impacchettati nel summenzionato .tar.xz file per il consumo da parte di pacman.
Questo sistema ha portato alla creazione di Arch User Repository (AUR), un repository guidato dalla comunità contenente file PKGBUILD e patch o script di supporto. Ciò consente la disponibilità di una quantità praticamente infinita di software in Arch. L'ovvio vantaggio di questo sistema è che se un utente (o un manutentore) desidera rendere il software disponibile al pubblico, non deve passare attraverso i canali ufficiali per farlo accettare nei repository principali. Lo svantaggio è che si basa sulla cura della community simile a Docker Hub, sui pacchetti Snap di Canonical o altri meccanismi simili. Esistono numerosi gestori di pacchetti specifici per AUR che possono essere utilizzati per scaricare, compilare e installare dai file PKGBUILD in AUR (ne parleremo più avanti).
Lavorare con pacman e repository ufficiali
Il principale gestore di pacchetti di Arch, pacman, usa flag invece di parole di comando come yum e apt . Ad esempio, per cercare un pacchetto, dovresti usare pacman -Ss . Come con la maggior parte dei comandi su Linux, puoi trovare sia una manpage e aiuto in linea. La maggior parte dei comandi per pacman usa la sincronizzazione (-S) bandiera. Ad esempio:
user@arch ~ $ pacman -Ss kate
extra/kate 18.04.2-2 (kde-applications kdebase)
Advanced Text Editor
extra/libkate 0.4.1-6 [installed]
A karaoke and text codec for embedding in ogg
extra/libtiger 0.3.4-5 [installed]
A rendering library for Kate streams using Pango and Cairo
extra/ttf-cheapskate 2.0-12
TTFonts collection from dustimo.com
community/haskell-cheapskate 0.1.1-100
Experimental markdown processor.
Arch utilizza anche repository simili ad altri gestori di pacchetti. Nell'output sopra, i risultati della ricerca sono preceduti dal repository in cui si trovano (extra/ e community/ in questo caso). Simile a entrambi i sistemi basati su Red Hat e Debian, Arch si affida all'utente per aggiungere le informazioni del repository in un file specifico. La posizione di questi repository è /etc/pacman.conf . L'esempio seguente è abbastanza simile a un sistema di stock. Ho abilitato il [multilib] repository per il supporto di Steam:
[options]
Architecture = auto
Color
CheckSpace
SigLevel = Required DatabaseOptional
LocalFileSigLevel = Optional
[core]
Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
[community]
Include = /etc/pacman.d/mirrorlist
[multilib]
Include = /etc/pacman.d/mirrorlist
È possibile specificare un URL specifico in pacman.conf . Questa funzionalità può essere utilizzata per assicurarsi che tutti i pacchetti provengano da un momento specifico. Se, ad esempio, un pacchetto ha un bug che ti colpisce gravemente e ha diverse dipendenze, puoi tornare a un momento specifico aggiungendo un URL specifico nel tuo pacman.conf e quindi eseguire i comandi per eseguire il downgrade del sistema:
[core]
Server=https://archive.archlinux.org/repos/2017/12/22/$repo/os/$arch
Come i sistemi basati su Debian, Arch non aggiorna le informazioni del suo repository locale finché non glielo dici tu. Puoi aggiornare il database del pacchetto eseguendo il comando seguente:
user@arch ~ $ sudo pacman -Sy
:: Synchronizing package databases...
core 130.2 KiB 851K/s 00:00 [##########################################################] 100%
extra 1645.3 KiB 2.69M/s 00:01 [##########################################################] 100%
community 4.5 MiB 2.27M/s 00:02 [##########################################################] 100%
multilib is up to date
Come puoi vedere nell'output sopra, pacman pensa che il database del pacchetto multilib sia aggiornato. Puoi forzare un aggiornamento se ritieni che non sia corretto eseguendo pacman -Syy . Se desideri aggiornare l'intero sistema (esclusi i pacchetti installati da AUR), puoi eseguire pacman -Syu :
user@arch ~ $ sudo pacman -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (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.4-1 lib32-harfbuzz-1.8.2-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.4-1 libmagick6-6.9.10.4-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 minetest-common-0.4.17.1-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
Total Download Size: 2.66 MiB
Total Installed Size: 879.15 MiB
Net Upgrade Size: -365.27 MiB
:: Proceed with installation? [Y/n]
Nello scenario menzionato in precedenza relativo al downgrade di un sistema, puoi forzare un downgrade emettendo pacman -Syyuu . È importante notare che questo non dovrebbe essere preso alla leggera. Ciò non dovrebbe causare problemi nella maggior parte dei casi; tuttavia, esiste la possibilità che il downgrade di uno o più pacchetti provochi un errore a cascata e lasci il sistema in uno stato incoerente. UTILIZZARE CON ATTENZIONE!
Per installare un pacchetto, usa semplicemente pacman -S kate :
user@arch ~ $ sudo pacman -S kate
resolving dependencies...
looking for conflicting packages...
Packages (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
Total Download Size: 10.94 MiB
Total Installed Size: 38.91 MiB
:: Proceed with installation? [Y/n]
Per rimuovere un pacchetto, puoi eseguire pacman -R kate . Questo rimuove solo il pacchetto e non le sue dipendenze:
user@arch ~ $ sudo pacman -S kate
checking dependencies...
Packages (1) kate-18.04.2-2
Total Removed Size: 20.30 MiB
:: Do you want to remove these packages? [Y/n]
Se vuoi rimuovere le dipendenze non richiesto da altri pacchetti, puoi eseguire pacman -Rs:
user@arch ~ $ sudo pacman -Rs kate
checking dependencies...
Packages (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
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 and 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.
Conclusione
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 <package>
dnf search <package>
zypper search <package>
apt-cache search <package>
apt search <package>
pacman -Ss <package>
# install packages
yum install <package>
dnf install <package>
zypper install <package>
apt-get install <package>
apt install <package>
pacman -S <package>
# 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 <package>
dnf remove <package>
apt-get remove <package>
apt remove <package>
pacman -R <package>
pacman -Rs <package>
# search for the package name containing specific file or folder
yum whatprovides *<binary>
dnf whatprovides *<binary>
zypper what-provides <binary>
zypper search --provides <binary>
apt-file search <binary>
pacman -Fs <binary>