Linux: paquetes y repositorios

Antes de teclear nada en una máquina desconocida hay que saber de qué familia es, porque de ahí sale todo lo demás: el gestor de paquetes, la ruta de los ficheros de configuración y hasta el nombre de los servicios. UNIX no es un producto sino una familia con muchos descendientes, y Linux es solo una de las ramas.

Dentro de Linux, lo que se instala nunca es el núcleo a secas sino una distribución: el núcleo más un gestor de paquetes, una selección de programas y unas decisiones de configuración. Las distribuciones se agrupan en pocas ramas, y las de cada rama comparten el formato de paquete.

Dos datos de historia reciente que se preguntan. CentOS era la versión gratuita y compatible de Red Hat Enterprise Linux, y al cambiar su modelo el relevo lo tomó Rocky Linux. Y macOS, aunque hoy parezca un mundo aparte, desciende de BSD, que es lo que explica que su terminal se parezca tanto a la de Linux.

El formato de paquete es la pista más rápida: .deb significa familia Debian y por tanto apt; .rpm significa familia Red Hat o SUSE y por tanto dnf o zypper.

Un administrador se encuentra dos escenarios muy distintos. En el normal, la máquina llega al repositorio y basta pedir el paquete por su nombre. En el otro, la máquina está aislada, alguien trae el fichero del paquete en la mano y hay que instalarlo tal cual. Cada escenario tiene su herramienta.

La diferencia no es de comodidad, es de capacidad: las herramientas de fichero no resuelven dependencias. Si el paquete que se instala a mano necesita otros, la instalación queda a medias y hay que rematarla. En la familia Debian, la orden que busca lo que falta y lo trae es apt install con la opción de arreglo.

dpkg -i agente-inventario_2.1_amd64.deb
apt install -f            # busca y resuelve lo que quedó pendiente
dpkg --configure -a       # termina de configurar paquetes a medias
dpkg -l | grep agente     # comprobar que quedó instalado

En la familia Red Hat, las tres letras de rpm -Uvh se preguntan por separado y conviene leerlas de una en una: U instala o actualiza según haga falta, v da salida detallada y h dibuja la barra de progreso.

rpm -Uvh agente-inventario-2.1.x86_64.rpm
rpm -qa | grep agente     # consultar todo lo instalado
rpm -e agente-inventario  # desinstalar

dpkg y rpm trabajan con el fichero que se les da y no salen a buscar nada. Resolver dependencias es cosa de apt y de dnf, que son los que hablan con el repositorio.

Un repositorio es un servidor que publica paquetes y un catálogo firmado que dice qué hay en él. La máquina no lo adivina: está escrito en un fichero de configuración, y saber cuál es lo primero que se toca cuando falla una instalación.

En la familia Debian, cada línea del fichero declara un origen con cuatro datos: si trae binarios o código fuente, la dirección del servidor, la versión de la distribución y las secciones que se aceptan. Es habitual añadir orígenes propios en ficheros aparte dentro del directorio, para no tocar el principal y poder quitarlos borrando un fichero.

# /etc/apt/sources.list.d/interno.list
deb https://paquetes.interno.llc/debian bookworm main

# después de tocar cualquier origen hay que refrescar el catálogo
apt update

En la familia Red Hat cada repositorio es un fichero con formato de secciones: un identificador, un nombre legible, la dirección base, si está activo y la clave con la que se comprueba la firma de los paquetes.

# /etc/yum.repos.d/interno.repo
[interno]
name=Repositorio interno
baseurl=https://paquetes.interno.llc/rocky/9/
enabled=1
gpgcheck=1

Ese gpgcheck no es un adorno: los repositorios van firmados y el gestor rechaza lo que no cuadre. Es la razón por la que añadir un origen nuevo obliga a instalar también su clave pública, y por la que apt update se queja cuando esa clave falta o ha caducado.

Debian declara repositorios en sources.list y en sources.list.d; Red Hat, en ficheros .repo dentro de /etc/yum.repos.d. Es de las preguntas de ruta más repetidas del temario.

El gestor de paquetes guarda dos cosas distintas en disco y confundirlas lleva a diagnósticos equivocados. Una es el catálogo descargado, es decir la lista de qué hay disponible y en qué versión. La otra son los ficheros de paquete que se han ido bajando para instalarlos.

Esa separación explica la trampa clásica de la familia Debian: hay una orden que refresca el catálogo y otra que instala lo nuevo, y no hacen lo mismo. Ejecutar solo la primera no actualiza nada; ejecutar solo la segunda actualiza contra una lista vieja.

La tercera forma existe porque a veces una actualización obliga a retirar algo, por ejemplo cuando un paquete se parte en dos o cambia de nombre. apt upgrade se planta antes que hacer eso; full-upgrade acepta el sacrificio. En la sintaxis antigua esa misma orden se llamaba dist-upgrade.

apt update && apt upgrade
apt full-upgrade
apt clean          # vacía los .deb descargados
apt autoremove     # quita dependencias que ya no usa nadie

apt update refresca el catálogo y apt upgrade instala. Una pregunta que diga que apt update actualiza el software es falsa, aunque el nombre invite a creerlo.

Por encima de las órdenes básicas hay capas pensadas para trabajar más cómodo. En la familia Debian son tres y conviene distinguirlas porque el examen las mezcla: aptitude funciona en modo texto con una interfaz de menús, dselect es el frontend histórico y synaptic es la aplicación de escritorio con ventanas.

Hay además dos órdenes muy parecidas que no son intercambiables. apt es la interfaz pensada para una persona: barra de progreso, colores y salida legible, que puede cambiar entre versiones. apt-get es la interfaz estable, la que se usa dentro de un guion precisamente porque su salida no va a cambiar de forma inesperada.

Para buscar en el catálogo, la orden vigente es apt search, que reemplazó a apt-cache search, y apt show para leer la ficha completa de un paquete concreto. En la familia Red Hat las equivalentes son dnf search, dnf info y dnf list.

apt search servidor-web
apt show apache2
dnf search servidor-web
dnf info httpd

Sobre dnf conviene un aviso de vigencia: en la familia Red Hat, yum fue el gestor durante años pero desde la versión 8 el gestor real es dnf, y yum se conserva como enlace por compatibilidad. Responder yum a una pregunta sobre un sistema actual es responder con el nombre antiguo.

Por último, una organización rara vez deja que cada máquina se descargue lo que quiera de internet. Lo habitual es montar un gestor de repositorios propio, del que Artifactory es el ejemplo más conocido, que hace de espejo y de almacén: guarda una copia controlada de los paquetes aprobados, de manera que todas las máquinas instalen exactamente las mismas versiones y se pueda reconstruir un sistema tal como estaba.

apt para el uso interactivo y apt-get dentro de guiones. Un repositorio propio no es un capricho: es lo que hace reproducible una instalación y lo que permite instalar sin salida a internet.