Cada dispositivo computarizado utiliza algún tipo de software para realizar las tareas previstas. En los primeros días del software, los productos se probaban rigurosamente en busca de errores y otros defectos. Durante la última década más o menos, se ha lanzado software a través de Internet con la intención de corregir cualquier error aplicando nuevas versiones del software. En algunos casos, cada aplicación individual tiene su propio actualizador. En otros, se deja al usuario decidir cómo obtener y actualizar el software.
Linux adoptó tempranamente la práctica de mantener una ubicación centralizada donde los usuarios pudieran encontrar e instalar software. En este artículo, hablaré sobre la historia de la instalación de software en Linux y cómo los sistemas operativos modernos se mantienen actualizados contra el torrente interminable de CVE.
¿Cómo se instalaba el software en Linux antes de los administradores de paquetes?
Históricamente, el software se proporcionaba a través de FTP o listas de correo (con el tiempo, esta distribución crecería para incluir sitios web básicos). Solo unos pocos archivos pequeños contenían las instrucciones para crear un binario (normalmente en un archivo tar). Descomprimiría los archivos, leería el archivo Léame y, siempre que tuviera GCC o alguna otra forma de compilador C, normalmente ejecutaría un ./configure secuencia de comandos con alguna lista de atributos, como la ruta a los archivos de la biblioteca, la ubicación para crear nuevos archivos binarios, etc. Además, el configure El proceso verificaría su sistema en busca de dependencias de aplicaciones. Si faltara algún requisito importante, el script de configuración se cerraría y no podría continuar con la instalación hasta que se cumplieran todas las dependencias. Si el script de configuración se completó con éxito, un Makefile se crearía.
Una vez que un Makefile existiera, entonces procedería a ejecutar make comando (este comando lo proporciona el compilador que estaba usando). El make El comando tiene varias opciones llamadas hacer banderas , que ayudan a optimizar los archivos binarios resultantes para su sistema. En los primeros días de la informática, esto era muy importante porque el hardware luchaba por mantenerse al día con las exigencias del software moderno. Hoy en día, las opciones de compilación pueden ser mucho más genéricas ya que la mayoría del hardware es más que adecuado para el software moderno.
Finalmente, después de make el proceso se había completado, necesitaría ejecutar make install (o sudo make install ) para instalar realmente el software. Como puede imaginar, hacer esto para cada pieza de software consumía mucho tiempo y era tedioso, sin mencionar el hecho de que actualizar el software era un proceso complicado y potencialmente muy complicado.
¿Qué es un paquete?
Los paquetes se inventaron para combatir esta complejidad. Los paquetes recopilan varios archivos de datos en un solo archivo para facilitar la portabilidad y el almacenamiento, o simplemente comprimen archivos para reducir el espacio de almacenamiento. Los archivos binarios incluidos en un paquete se precompilan de acuerdo con los valores predeterminados que eligió el desarrollador. Los paquetes también contienen metadatos, como el nombre del software, una descripción de su propósito, un número de versión y una lista de dependencias necesarias para que el software funcione correctamente.
Varias versiones de Linux han creado sus propios formatos de paquetes. Algunos de los formatos de paquete más utilizados incluyen:
- .deb:Debian, Ubuntu, Linux Mint y varios otros derivados utilizan este formato de paquete. Fue el primer tipo de paquete que se creó.
- .rpm:este formato de paquete originalmente se llamaba Red Hat Package Manager. Lo utilizan Red Hat, Fedora, SUSE y otras distribuciones más pequeñas.
- .tar.xz:si bien es solo un tarball comprimido, este es el formato que utiliza Arch Linux.
Si bien los paquetes en sí mismos no administran las dependencias directamente, representaron un gran paso adelante en la administración de software de Linux.
¿Qué es un repositorio de software?
Hace unos años, antes de la proliferación de los teléfonos inteligentes, la idea de un repositorio de software era difícil de comprender para muchos usuarios si no estaban involucrados en el ecosistema Linux. Hasta el día de hoy, la mayoría de los usuarios de Windows todavía parecen estar programados para abrir un navegador web para buscar e instalar un nuevo software. Sin embargo, aquellos con teléfonos inteligentes se han acostumbrado a la idea de una "tienda" de software. La forma en que los usuarios de teléfonos inteligentes obtienen el software y la forma en que funcionan los administradores de paquetes no son diferentes. Si bien ha habido varios intentos de crear una interfaz de usuario atractiva para los repositorios de software, la gran mayoría de los usuarios de Linux todavía usan la línea de comandos para instalar paquetes. Los repositorios de software son una lista centralizada de todo el software disponible para cualquier repositorio que el sistema haya configurado para usar. A continuación, se incluyen algunos ejemplos de búsqueda de un paquete específico en un repositorio (tenga en cuenta que estos se han truncado por razones de brevedad):
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 usando 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
¿Cuáles son los administradores de paquetes más destacados?
Como se sugiere en el resultado anterior, los administradores de paquetes se utilizan para interactuar con los repositorios de software. La siguiente es una breve descripción general de algunos de los administradores de paquetes más destacados.
Administradores de paquetes basados en RPM
La actualización de sistemas basados en RPM, particularmente aquellos basados en tecnologías Red Hat, tiene una historia muy interesante y detallada. De hecho, las versiones actuales de yum (para distribuciones empresariales) y DNF (para comunidad) combinan varios proyectos de código abierto para proporcionar su funcionalidad actual.
Inicialmente, Red Hat usaba un administrador de paquetes llamado RPM (Red Hat Package Manager), que todavía se usa en la actualidad. Sin embargo, su uso principal es para instalar RPM, que tiene localmente, no para buscar repositorios de software. El administrador de paquetes llamado up2date fue creado para informar a los usuarios sobre las actualizaciones de los paquetes y permitirles buscar repositorios remotos e instalar dependencias fácilmente. Si bien cumplió su propósito, algunos miembros de la comunidad sintieron que up2date tenía algunas deficiencias significativas.
El encantamiento actual de yum provino de varios esfuerzos comunitarios diferentes. Yellowdog Updater (YUP) fue desarrollado en 1999-2001 por la gente de Terra Soft Solutions como un motor de back-end para un instalador gráfico de Yellow Dog Linux. A la Universidad de Duke le gustó la idea de YUP y decidió mejorarla. Crearon Yellowdog Updater, Modified (yum), que eventualmente se adaptó para ayudar a administrar los sistemas Red Hat Linux de la universidad. Yum creció en popularidad y, en 2005, se estimaba que lo utilizaba más de la mitad del mercado de Linux. Hoy en día, casi todas las distribuciones de Linux que usan RPM usan yum para la administración de paquetes (con algunas excepciones notables).
Trabajar con yum
Para que yum descargue e instale paquetes desde un repositorio de Internet, los archivos deben estar ubicados en /etc/yum.repos.d/ y deben tener la extensión .repo . Aquí hay un archivo de repositorio de ejemplo:
[local_base]
name=Base CentOS (local)
baseurl=http://7-repo.apps.home.local/yum-repo/7/
enabled=1
gpgcheck=0
Esto es para uno de mis repositorios locales, lo que explica por qué la verificación de GPG está desactivada. Si esta verificación estuviera activada, cada paquete debería firmarse con una clave criptográfica y la clave correspondiente debería importarse al sistema que recibe las actualizaciones. Como yo mismo mantengo este repositorio, confío en los paquetes y no me molesto en firmarlos.
Una vez que el archivo del repositorio está en su lugar, puede comenzar a instalar paquetes desde el repositorio remoto. El comando más básico es yum update , que actualizará todos los paquetes actualmente instalados. Esto no requieren un paso específico para actualizar la información sobre los repositorios; esto se hace automáticamente. A continuación se muestra un ejemplo 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
Si está seguro de que desea que yum ejecute cualquier comando sin detenerse para ingresar, puede poner el -y marca en el comando, como yum update -y .
Instalar un nuevo paquete es igual de fácil. Primero, busque el nombre del paquete 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 vez que tenga el nombre del paquete, simplemente puede instalar el paquete con sudo yum install kate-devel -y . Si instaló un paquete que ya no necesita, puede eliminarlo con sudo yum remove kate-devel -y . De forma predeterminada, yum eliminará el paquete y sus dependencias.
Puede haber ocasiones en las que no sepa el nombre del paquete, pero sí el nombre de la utilidad. Por ejemplo, suponga que está buscando la utilidad updatedb , que crea/actualiza la base de datos utilizada por locate dominio. Intentando instalar updatedb devuelve los siguientes resultados:
[user@centos ~]$ sudo yum install updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
No package updatedb available.
Error: Nothing to do
Puede averiguar de qué paquete proviene la utilidad ejecutando:
[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
La razón por la que he usado un asterisco * delante del comando es porque yum whatprovides usa la ruta al archivo para hacer una coincidencia. Como no estaba seguro de dónde se encontraba el archivo, usé un asterisco para indicar cualquier ruta.
Hay, por supuesto, muchas más opciones disponibles para yum. Le animo a que consulte la página de manual de yum para obtener opciones adicionales.
Dandified Yum (DNF) es una versión más reciente de yum. Introducido en Fedora 18, aún no se ha adoptado en las distribuciones empresariales y, como tal, se usa predominantemente en Fedora (y derivados). Su uso es casi exactamente el mismo que el de yum, pero se creó para abordar el rendimiento deficiente, las API no documentadas, la resolución de dependencia lenta/rota y el uso ocasional de memoria alta. DNF está diseñado como un reemplazo directo de yum y, por lo tanto, no repetiré los comandos, donde sea que use yum , simplemente sustituya dnf .
Trabajar con Zypper
Zypper es otro administrador de paquetes destinado a ayudar a administrar los RPM. Este administrador de paquetes se asocia más comúnmente con SUSE (y openSUSE), pero también ha sido adoptado por MeeGo, Sailfish OS y Tizen. Se introdujo originalmente en 2006 y se ha repetido desde entonces. No hay mucho que decir aparte de que Zypper se usa como back-end para la herramienta de administración del sistema YaST y algunos usuarios consideran que es más rápido que yum.
El uso de Zypper es muy similar al de yum. Para buscar, actualizar, instalar o eliminar un paquete, simplemente use lo siguiente:
zypper search kate
zypper update
zypper install kate
zypper remove kate
Algunas diferencias importantes entran en juego en cómo se agregan los repositorios al sistema con zypper . A diferencia de los administradores de paquetes discutidos anteriormente, zypper agrega repositorios utilizando el propio administrador de paquetes. La forma más común es a través de una URL, pero zypper también admite la importación desde archivos de repositorio.
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
Elimina repositorios de manera similar:
suse:~ # zypper removerepo vlc
Removing repository 'vlc' ...................................[done]
Repository 'vlc' has been removed.
Usa los zypper repos comando para ver cuál es el estado de los repositorios en su 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 incluso tiene una capacidad similar para determinar qué nombre de paquete contiene archivos o binarios. A diferencia de YUM, usa un guión en el comando (aunque este método de búsqueda está en desuso):
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
Al igual que con YUM y DNF, Zypper tiene un conjunto de funciones mucho más rico que el que se cubre aquí. Consulte la documentación oficial para obtener información más detallada.
Administradores de paquetes basados en Debian
Una de las distribuciones de Linux más antiguas que se mantienen actualmente, el sistema de Debian es muy similar a los sistemas basados en RPM. Usan .deb paquetes, que pueden ser administrados por una herramienta llamada dpkg . dpkg es muy similar a rpm en que fue diseñado para administrar paquetes que están disponibles localmente. No resuelve las dependencias (aunque sí verifica las dependencias) y no tiene una forma confiable de interactuar con los repositorios remotos. Para mejorar la experiencia del usuario y la facilidad de uso, el proyecto Debian encargó un proyecto llamado Deity . Este nombre en clave finalmente se abandonó y se cambió a Herramienta de paquete avanzado (APT).
Lanzado como versiones de prueba en 1998 (antes de aparecer en Debian 2.1 en 1999), muchos usuarios consideran que APT es una de las características definitorias de los sistemas basados en Debian. Hace uso de repositorios de manera similar a los sistemas basados en RPM, pero en lugar de .repo individuales archivos que yum usos, apt ha usado históricamente /etc/apt/sources.list para gestionar repositorios. Más recientemente, también ingiere archivos de /etc/apt/sources.d/ . Siguiendo los ejemplos de los administradores de paquetes basados en RPM, para lograr lo mismo en las distribuciones basadas en Debian, tiene algunas opciones. Puede editar/crear los archivos manualmente en las ubicaciones antes mencionadas desde la terminal o, en algunos casos, puede usar una interfaz de interfaz de usuario (como Software & Updates proporcionada por Ubuntu et al.). Para proporcionar el mismo tratamiento a todas las distribuciones, cubriré solo las opciones de la línea de comandos. Para agregar un repositorio sin editar directamente un archivo, puede hacer algo como esto:
user@ubuntu:~$ sudo apt-add-repository "deb http://APT.spideroak.com/ubuntu-spideroak-hardy/ release restricted"
Esto creará una spideroakone.list archivo en /etc/apt/sources.list.d . Obviamente, estas líneas cambian según el repositorio que se agregue. Si está agregando un archivo de paquete personal (PPA), puede hacer esto:
user@ubuntu:~$ sudo apt-add-repository ppa:gnome-desktopNOTA: Debian no es compatible con los PPA de forma nativa.
Después de agregar un repositorio, los sistemas basados en Debian deben saber que hay una nueva ubicación para buscar paquetes. Esto se hace a través de 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
Ahora que se agregó y actualizó el nuevo repositorio, puede buscar un paquete usando 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
Para instalar kate , simplemente ejecute el comando de instalación correspondiente:
user@ubuntu:~$ sudo apt-get install kate
Para eliminar un paquete, use apt-get remove :
user@ubuntu:~$ sudo apt-get remove kate
Cuando se trata del descubrimiento de paquetes, APT no proporciona ninguna funcionalidad similar a yum whatprovides . Hay algunas formas de obtener esta información si está tratando de encontrar de dónde proviene un archivo específico en el disco.
Uso de dpkg
user@ubuntu:~$ dpkg -S /bin/ls
coreutils: /bin/ls
Usando el archivo apt
user@ubuntu:~$ sudo apt-get install apt-file -y
user@ubuntu:~$ sudo apt-file update
user@ubuntu:~$ apt-file search kate
El problema con la apt-file search es eso, a diferencia de yum whatprovides , es demasiado detallado a menos que sepa la ruta exacta, y agrega automáticamente una búsqueda con comodines para que termine con resultados para cualquier cosa con la palabra kate en ella:
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 mayoría de estos ejemplos han usado apt-get . Tenga en cuenta que la mayoría de los tutoriales actuales para Ubuntu se han centrado específicamente en usar apt . El único apt El comando fue diseñado para implementar solo los comandos más utilizados en el arsenal APT. Dado que la funcionalidad se divide entre apt-get , apt-cache y otros comandos, apt busca unificarlos en un solo comando. También agrega algunas sutilezas, como coloración, barras de progreso y otras probabilidades y extremos. La mayoría de los comandos mencionados anteriormente se pueden reemplazar con apt , pero no todas las distribuciones basadas en Debian que actualmente reciben parches de seguridad son compatibles con apt de forma predeterminada, por lo que es posible que deba instalar paquetes adicionales.
Administradores de paquetes basados en arquitectura
Arch Linux usa un administrador de paquetes llamado pacman. A diferencia de .deb o .rpm archivos, pacman usa un tarball más tradicional con el LZMA2 compresión (.tar.xz ). Esto permite que los paquetes de Arch Linux sean mucho más pequeños que otras formas de archivos comprimidos (como gzip ). Lanzado inicialmente en 2002, pacman se ha iterado y mejorado constantemente. Uno de los principales beneficios de pacman es que es compatible con Arch Build System, un sistema para crear paquetes desde el origen. El sistema de compilación ingiere un archivo llamado PKGBUILD, que contiene metadatos (como números de versión, revisiones, dependencias, etc.), así como un script de shell con los indicadores necesarios para compilar un paquete que cumpla con los requisitos de Arch Linux. Los archivos binarios resultantes se empaquetan en el .tar.xz antes mencionado. archivo para el consumo de pacman.
Este sistema condujo a la creación del Arch User Repository (AUR), que es un repositorio impulsado por la comunidad que contiene archivos PKGBUILD y parches o scripts compatibles. Esto permite que una cantidad virtualmente infinita de software esté disponible en Arch. La ventaja obvia de este sistema es que si un usuario (o mantenedor) desea que el software esté disponible para el público, no tiene que pasar por los canales oficiales para que sea aceptado en los repositorios principales. La desventaja es que se basa en la curación de la comunidad similar a Docker Hub, los paquetes Snap de Canonical u otros mecanismos similares. Existen numerosos administradores de paquetes específicos de AUR que se pueden usar para descargar, compilar e instalar desde los archivos PKGBUILD en AUR (veremos esto más adelante).
Trabajar con pacman y repositorios oficiales
El administrador de paquetes principal de Arch, pacman, usa banderas en lugar de palabras de comando como yum y apt . Por ejemplo, para buscar un paquete, usaría pacman -Ss . Como con la mayoría de los comandos en Linux, puede encontrar una manpage y ayuda en línea. La mayoría de los comandos para pacman usa la sincronización (-S) bandera. Por ejemplo:
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 también usa repositorios similares a otros administradores de paquetes. En el resultado anterior, los resultados de la búsqueda tienen el prefijo del repositorio en el que se encuentran (extra/ y community/ en este caso). Al igual que los sistemas basados en Red Hat y Debian, Arch confía en que el usuario agregue la información del repositorio a un archivo específico. La ubicación de estos repositorios es /etc/pacman.conf . El siguiente ejemplo es bastante parecido a un sistema de acciones. He habilitado el [multilib] repositorio para el soporte de 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
Es posible especificar una URL específica en pacman.conf . Esta funcionalidad se puede usar para asegurarse de que todos los paquetes provengan de un momento específico. Si, por ejemplo, un paquete tiene un error que lo afecta gravemente y tiene varias dependencias, puede retroceder a un punto específico en el tiempo agregando una URL específica en su pacman.conf y luego ejecutar los comandos para degradar el sistema:
[core]
Server=https://archive.archlinux.org/repos/2017/12/22/$repo/os/$arch
Al igual que los sistemas basados en Debian, Arch no actualiza la información de su repositorio local hasta que usted le indique que lo haga. Puede actualizar la base de datos del paquete emitiendo el siguiente comando:
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
Como puede ver en el resultado anterior, pacman piensa que la base de datos del paquete multilib está actualizada. Puede forzar una actualización si cree que esto es incorrecto ejecutando pacman -Syy . Si desea actualizar todo su sistema (excluyendo los paquetes instalados desde AUR), puede ejecutar 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]
En el escenario mencionado anteriormente con respecto a la degradación de un sistema, puede forzar una degradación ejecutando pacman -Syyuu . Es importante señalar que esto no debe tomarse a la ligera. Esto no debería causar ningún problema en la mayoría de los casos; sin embargo, existe la posibilidad de que la degradación de uno o varios paquetes cause una falla en cascada y deje su sistema en un estado inconsistente. ¡UTILICE CON PRECAUCIÓN!
Para instalar un paquete, simplemente use 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]
Para eliminar un paquete, puede ejecutar pacman -R kate . Esto elimina solo el paquete y no sus dependencias:
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]
Si desea eliminar las dependencias que no requerido por otros paquetes, puede ejecutar 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.
Conclusión
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>