Otros gestores de paquetes

1. Las familias de distribuciones

En el tema 1 dijimos que una distribución es el kernel de Linux más una selección de programas, lista para instalar. Hay cientos, pero casi todas descienden de unas pocas, y lo que más claramente hereda una distribución de su antecesora es el formato de sus paquetes y el programa que los administra.

Los formatos no son intercambiables. Un .deb no se instala en Fedora, ni un .rpm en Ubuntu: aunque el programa de adentro sea el mismo, cada paquete nombra sus dependencias con los nombres que tienen en su distribución, y espera encontrar las bibliotecas en las versiones que esa distribución trae. Por eso las páginas de descarga ofrecen un archivo por familia, y por eso existen los formatos universales de la segunda mitad del tema.

Lo que sí es común son los conceptos del tema 35: paquete, repositorio firmado, dependencias, una base de datos de lo instalado, y la división entre consultar, que hace cualquier usuario, y modificar, que requiere sudo. Quien entendió apt ya entendió los demás; le falta aprender cómo se llama cada cosa.

2. Saber qué distribución y qué gestor tienes

Frente a una máquina desconocida —un servidor al que se entra por ssh, una máquina virtual, un contenedor—, lo primero es identificarla. Todas las distribuciones actuales se presentan en un mismo archivo, /etc/os-release:

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.3 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
…

El archivo tiene la forma NOMBRE=valor de las variables del tema 34, y no por casualidad: está pensado para que un script lo cargue con source. Las dos líneas resaltadas son las que importan aquí.

$ grep -E '^(ID|ID_LIKE)=' /etc/os-release
ID=linuxmint                    # Linux Mint
ID_LIKE="ubuntu debian"

ID=fedora                       # Fedora: no tiene ID_LIKE, es cabeza de familia

ID="rocky"                      # Rocky Linux
ID_LIKE="rhel centos fedora"

ID=manjaro                      # Manjaro
ID_LIKE=arch

La otra manera es preguntarle a la shell qué gestores encuentra, con el type del tema 3:

$ type apt dnf pacman zypper apk snap flatpak 2> /dev/null
apt is /usr/bin/apt
snap is /usr/bin/snap

Los que no existen producen un error, que el 2> /dev/null descarta; quedan los que sí. En este Ubuntu hay dos, y esa es la situación normal hoy: un gestor de la distribución, y al lado uno o dos de los universales.

3. dnf: Fedora y la familia Red Hat

dnf es a la familia Red Hat lo que apt a la de Debian: el gestor de alto nivel, que consulta los repositorios, resuelve las dependencias y encarga la instalación a la herramienta de abajo, rpm. Es el sucesor de yum, y en los sistemas actuales yum es solo otro nombre del mismo programa: los tutoriales que dicen yum install siguen funcionando.

Sus subcomandos se parecen tanto a los de apt que casi no hay que traducir:

$ sudo dnf install mc
Last metadata expiration check: 0:12:44 ago on Mon 12 Oct 2026 10:31:07 PM.
Dependencies resolved.
================================================================================
 Package          Architecture    Version               Repository        Size
================================================================================
Installing:
 mc               x86_64          1:4.8.33-1.fc42       fedora           2.1 M
Installing dependencies:
 gpm-libs         x86_64          1.20.7-48.fc42        fedora            20 k

Transaction Summary
================================================================================
Install  2 Packages

Total download size: 2.1 M
Installed size: 7.6 M
Is this ok [y/N]: 

La estructura es la que ya sabemos leer: qué se pidió, qué dependencias se agregan, de qué repositorio sale cada paquete, cuánto se descarga, cuánto ocupará, y una pregunta. El dibujo de la tabla cambia entre versiones de dnf; la información es la misma.

Hay tres diferencias de comportamiento con apt que conviene conocer, porque no son de nombre sino de fondo.

La segunda fila es la trampa para quien cambia de familia. sudo apt update es inofensivo; sudo dnf update actualiza el sistema entero.

dnf check-update tiene un detalle útil para lo aprendido en el tema 25: su código de salida es 0 si no hay nada que actualizar y 100 si lo hay. No es un error; es la manera de que un script pueda preguntar «¿hay actualizaciones?». Y dnf provides resuelve con un solo comando lo que en Ubuntu pedía instalar apt-file: ante un command not found, dice qué paquete hay que instalar.

4. rpm: consultar lo instalado

El nombre de un paquete .rpm tiene las mismas piezas que el de un .deb, con otros separadores:

mc-4.8.33-1.fc42.x86_64.rpm
 │    │   │  │     │
 │    │   │  │     └─ la arquitectura: x86_64 es lo que Debian llama amd64; «noarch», cualquiera
 │    │   │  └─ la distribución: Fedora 42. En RHEL y derivadas, «el9», «el10»
 │    │   └─ la revisión del paquete
 │    └─ la versión del programa
 └─ el nombre

rpm cumple el papel de dpkg: instala archivos sueltos sin resolver dependencias, y sobre todo consulta la base de datos de lo instalado. Todas sus consultas empiezan con -q, de query, seguida de una letra que indica qué se pregunta.

$ rpm -q mc                             # ¿está instalado?
mc-4.8.33-1.fc42.x86_64
$ rpm -q ncdu
package ncdu is not installed
$ rpm -qa | wc -l                       # todos los instalados
1912
$ rpm -ql mc | grep /bin/               # los archivos de un paquete
/usr/bin/mc
/usr/bin/mcdiff
/usr/bin/mcedit
/usr/bin/mcview
$ rpm -qf /usr/bin/sort                 # el paquete de un archivo
coreutils-9.6-2.fc42.x86_64

La p se agrega a cualquier consulta para dirigirla a un archivo .rpm en lugar de a la base de datos: rpm -qpi archivo.rpm muestra la ficha de un paquete descargado, antes de instalarlo. Y la última fila es una función que dpkg no ofrece de manera tan directa: rpm -V compara cada archivo del paquete con lo que se instaló, y señala los que fueron modificados o borrados. Si no escribe nada, todo está como llegó.

Para instalar, la recomendación es la del tema anterior: sudo dnf install ./archivo.rpm, y no rpm -i, que falla si falta una dependencia.

5. Repositorios e historial en dnf

Los repositorios se configuran en /etc/yum.repos.d/, con un archivo .repo por cada uno; el nombre del directorio recuerda al antecesor. dnf repolist los enumera:

$ dnf repolist
repo id                 repo name
fedora                  Fedora 42 - x86_64
fedora-cisco-openh264   Fedora 42 openh264 (From Cisco) - x86_64
updates                 Fedora 42 - x86_64 - Updates
$ ls /etc/yum.repos.d/
fedora-cisco-openh264.repo  fedora.repo  fedora-updates.repo  fedora-updates-testing.repo

El reparto es el de Ubuntu con otros nombres: fedora es la versión tal como se publicó, y updates, las correcciones. Los repositorios adicionales más conocidos de la familia:

Donde dnf aventaja con claridad a apt es en el historial. No hay que leer un archivo de registro: hay un subcomando, y las operaciones se pueden deshacer.

$ dnf history
ID  Command line          Date and time        Action(s)   Altered
 27 dnf install mc        2026-10-12 22:44     Install           2
 26 dnf upgrade           2026-10-11 09:12     Upgrade          64
 25 dnf remove gimp       2026-10-08 18:30     Removed           9
$ dnf history info 27               # el detalle: qué paquetes, quién lo pidió
$ sudo dnf history undo 27          # deshace esa operación: quita mc y gpm-libs

dnf history undo hace la operación inversa de una transacción: desinstala lo que instaló, reinstala lo que quitó. Es la respuesta directa a «instalé algo y trajo veinte paquetes que no quiero».

6. pacman: Arch y sus derivadas

pacman rompe con el estilo de los anteriores. No tiene subcomandos con palabras, sino operaciones de una letra mayúscula, a las que se agregan letras minúsculas que las modifican. Es más críptico al principio, y muy breve una vez aprendido.

sudo pacman -Syu
             │││
             ││└─ u: actualizar los paquetes instalados (upgrade)
             │└─ y: renovar antes la lista de paquetes
             └─ S: la operación. «Sync», trabajar con los repositorios

Las minúsculas tienen un significado bastante constante de una operación a otra, y eso es lo que hace memorizable el sistema: s busca, i informa, l lista archivos. -Ss busca en los repositorios y -Qs busca entre lo instalado; -Si da la ficha de un paquete disponible y -Qi la de uno instalado.

$ pacman -Ss '^mc$'
extra/mc 4.8.33-1
    A file manager that emulates Norton Commander
$ sudo pacman -S mc
resolving dependencies...
looking for conflicting packages...

Packages (2) libssh2-1.11.1-1  mc-4.8.33-1

Total Download Size:   2.05 MiB
Total Installed Size:  8.31 MiB

:: Proceed with installation? [Y/n] 
$ pacman -Q mc
mc 4.8.33-1
$ pacman -Qo /usr/bin/sort
/usr/bin/sort is owned by coreutils 9.7-1

La salida de -Ss antepone el repositorio al nombre: extra/mc. Arch tiene dos repositorios principales, core, con la base del sistema, y extra, con todo lo demás; se configuran en /etc/pacman.conf, y los servidores desde los que se descargan, en /etc/pacman.d/mirrorlist.

Sin la n, pacman -R conserva los archivos de configuración modificados, con extensión .pacsave. Y en las actualizaciones, cuando un paquete trae una versión nueva de un archivo de configuración que cambiaste, la deja al lado como .pacnew para que la compares con diff: es la misma política de las tres familias, con tres extensiones distintas. El registro de todo lo hecho está en /var/log/pacman.log.

7. Actualización continua y AUR

Arch se diferencia de Ubuntu y de Fedora en algo más profundo que su gestor: no tiene versiones.

Una distribución de versiones fijas publica cada cierto tiempo una versión, congela en ella las versiones de sus programas y durante su vida útil solo les aplica correcciones. Una de actualización continua, o rolling release, no tiene versiones: cada programa se actualiza a la última en cuanto está lista, y el sistema se mantiene al día con un solo comando, indefinidamente.

La otra pieza característica es el AUR, Arch User Repository. No es un repositorio de paquetes: es una colección, mantenida por los usuarios, de recetas para construir paquetes. Cada receta es un script que descarga el programa de su origen, lo compila y arma un paquete que luego pacman instala. Así hay disponible prácticamente cualquier programa que exista para Linux. Se usa a través de programas auxiliares, como yay o paru, que aceptan las mismas letras que pacman. Y pide más cuidado que un PPA: nadie revisa esas recetas antes de publicarlas, de modo que quien instala del AUR es quien debe leer el script primero.

8. La tabla de equivalencias

Todo lo anterior, reunido. Es la tabla para tener a mano cuando un tutorial habla en otro dialecto.

La traducción de los comandos es casi mecánica. La de los nombres de los paquetes, no: cada distribución bautiza los suyos. El servidor web Apache es apache2 en Debian, httpd en Fedora y apache en Arch; los archivos para compilar contra una biblioteca terminan en -dev en Debian y en -devel en Fedora. Cuando un tutorial dice apt install libssl-dev y estás en Fedora, traducir apt por dnf no alcanza: hay que buscar el nombre, con dnf search openssl.

Las dos familias que quedan siguen el estilo de subcomandos, y se leen sin esfuerzo:

apk merece recordarse por una razón práctica: Alpine es la base de muchísimas imágenes de contenedores, y es probable que el primer apk add que encuentres esté dentro de un archivo de Docker.

9. Los formatos universales

El modelo del paquete tradicional tiene dos límites, que el tema anterior dejó planteados. Quien publica un programa debe preparar un paquete por cada familia, y a veces por cada versión de cada distribución. Y el usuario de una distribución de versiones fijas se queda con la versión del programa que había cuando se publicó la suya. Los formatos universales atacan los dos problemas a la vez.

Un paquete universal contiene la aplicación junto con las bibliotecas que necesita, de modo que el mismo paquete funciona en cualquier distribución. Lo publica directamente quien desarrolla el programa, se ejecuta aislado del resto del sistema, y se actualiza por su cuenta, con independencia de la versión de la distribución.

La última fila es el precio. Las ventajas del tema 35 sobre las bibliotecas compartidas se pierden, y a cambio se gana independencia. Por eso los dos modelos conviven en lugar de reemplazarse: el sistema base y las herramientas de la terminal siguen llegando como paquetes de la distribución, y las aplicaciones grandes de escritorio —navegadores, editores, programas de mensajería— tienden a llegar en formato universal.

Hay tres formatos, con filosofías distintas:

10. snap

En Ubuntu, snap viene instalado y ya tiene trabajo: varias aplicaciones del sistema llegan en ese formato. Lo comprobamos con el caso que dejamos pendiente en el tema anterior.

$ dpkg -l firefox | tail -n 1
ii  firefox        1:1snap1-0ubuntu5 amd64        Transitional package - firefox -> firefox snap
$ snap list
Name                       Version          Rev    Tracking         Publisher   Notes
bare                       1.0              5      latest/stable    canonical✓  base
core22                     20250923         2139   latest/stable    canonical✓  base
firefox                    143.0.4-1        7024   latest/stable/…  mozilla✓    -
gnome-42-2204              0+git.38ea591    202    latest/stable/…  canonical✓  -
gtk-common-themes          0.1-81-g442e511  1535   latest/stable/…  canonical✓  -
snap-store                 0+git.90575829   1270   2/stable/…       canonical✓  -
snapd                      2.71             25202  latest/stable    canonical✓  snapd

El paquete .deb llamado firefox existe, pero es «de transición»: no contiene el navegador, sino un encargo de instalar el snap. Y el snap lo publica Mozilla, no Ubuntu: la marca junto al nombre indica un editor verificado.

Los snaps marcados como base no son aplicaciones: son el sistema mínimo sobre el que corren las demás, la parte compartida que evita que cada snap traiga absolutamente todo. snapd es el servicio que administra el conjunto.

Buscar, instalar y quitar

Los subcomandos siguen el estilo conocido. Para practicar usamos hello-world, un snap diminuto que Canonical mantiene para pruebas:

$ snap find hello-world | head -n 3
Name               Version  Publisher    Notes  Summary
hello-world        6.4      canonical✓   -      The 'hello-world' of snaps
hello-world-gui    0.1      snapcrafters -      A simple GUI hello world
$ sudo snap install hello-world
hello-world 6.4 from Canonical✓ installed
$ hello-world
Hello World!
$ type hello-world
hello-world is /snap/bin/hello-world

No hubo lista de dependencias ni pregunta: un snap se basta a sí mismo. Y la última línea explica un detalle del tema 34: aquel /snap/bin que aparecía al final de PATH es el directorio donde snapd publica los comandos de los snaps instalados.

Actualizaciones automáticas, canales y vuelta atrás

La diferencia de conducta más notable con apt es que los snaps se actualizan solos. snapd consulta la tienda varias veces al día e instala las revisiones nuevas sin preguntar. snap refresh existe para adelantar ese momento, no porque haga falta. Quien necesite controlar cuándo ocurre puede posponerlo, con sudo snap refresh --hold=72h, o retener un snap en particular.

Como contrapartida, snapd conserva la revisión anterior de cada snap, y con snap revert se vuelve a ella en segundos: es la red de seguridad para cuando una actualización automática rompe algo.

Cada snap se publica en varios canales, que indican cuán probada está la versión:

$ snap info firefox | grep -A 5 '^channels'
channels:
  latest/stable:    143.0.4-1  2026-10-07 (7024) 251MB -
  latest/candidate: 144.0-2    2026-10-09 (7061) 252MB -
  latest/beta:      145.0b3-1  2026-10-11 (7077) 254MB -
  latest/edge:      146.0a1    2026-10-12 (7084) 258MB -
  esr/stable:       140.4.0esr 2026-10-07 (7019) 247MB -

Delante del nivel va la pista, track: latest es la línea principal, y un programa puede ofrecer otras para sus versiones de soporte prolongado, como el esr de Firefox. Se elige al instalar, sudo snap install firefox --channel=esr/stable, o se cambia después, con sudo snap refresh firefox --channel=…. Es la solución a un problema que con apt pedía agregar un PPA: tener una versión distinta de la que ofrece la distribución.

Confinamiento

El confinamiento es el aislamiento con que se ejecuta un snap: el programa no ve el sistema entero, sino una versión restringida, y solo accede a los recursos —la red, la cámara, tus archivos— para los que tiene declarada y concedida una interfaz.

El modo classic existe porque algunos programas necesitan, por su naturaleza, acceso a todo el sistema: los editores de código, los compiladores, las herramientas de administración. La tienda los revisa antes de admitirlos, y snap obliga a pedirlo expresamente: sin la opción --classic, la instalación se niega con un mensaje que explica por qué. Las interfaces de un snap estricto se consultan con snap connections nombre.

Dónde queda todo

La palabra «montado» tiene una consecuencia visible. Un snap no se desempaqueta en el disco: su archivo se monta como si fuera un pequeño disco de solo lectura, y por eso cada snap instalado aparece como un dispositivo loop en la salida de df, lsblk y mount. Son esas líneas, que no corresponden a ningún disco real, las que aprenderemos a filtrar en el tema 38.

La última fila explica por qué un programa instalado como snap parece «no ver» algunos archivos: confinado, trabaja en su propio directorio dentro de ~/snap, y solo llega a tu directorio personal si tiene la interfaz correspondiente; a los archivos ocultos y a otros discos, a veces ni así.

11. flatpak

flatpak persigue lo mismo que snap, con otras decisiones. Se ocupa solo de aplicaciones gráficas; no depende de una tienda única, aunque en la práctica casi todo está en una, Flathub; y puede instalar para un solo usuario, sin privilegios. Viene de fábrica en Fedora y en Linux Mint. En Ubuntu hay que instalarlo, y decirle de dónde descargar:

$ sudo apt install flatpak
$ flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
$ flatpak remotes
Name    Options
flathub system

Un remoto es, en el vocabulario de flatpak, lo que venimos llamando repositorio. Después de agregar el primero conviene cerrar la sesión y volver a entrar, para que las aplicaciones aparezcan en el menú del escritorio.

Las aplicaciones no se identifican por un nombre corto sino por un identificador con forma de dominio de Internet escrito al revés, que garantiza que no haya dos iguales:

org.gnome.Calculator
 │    │       │
 │    │       └─ el nombre de la aplicación
 │    └─ quien la desarrolla: el proyecto GNOME
 └─ su dominio, invertido: gnome.org

$ flatpak search calculator | head -n 3
Name          Description                        Application ID          Version  Branch  Remotes
Calculator    Perform arithmetic, scientific…    org.gnome.Calculator    48.1     stable  flathub
Qalculate!    Powerful and easy to use…          io.github.Qalculate     5.5.2    stable  flathub
$ flatpak install flathub org.gnome.Calculator
Looking for matches…
Required runtime for org.gnome.Calculator/x86_64/stable (runtime/org.gnome.Platform/x86_64/48) found in remote flathub
Do you want to install it? [Y/n]: y

        ID                                     Branch    Op   Remote    Download
 1.     org.freedesktop.Platform.GL.default    24.08     i    flathub   < 156.2 MB
 2.     org.gnome.Platform                     48        i    flathub   < 380.5 MB
 3.     org.gnome.Calculator                   stable    i    flathub   <   3.4 MB

Proceed with these changes to the system installation? [Y/n]: 

Una calculadora de tres megabytes pide descargar más de quinientos. La explicación está en las dos primeras líneas de la lista.

Un runtime es un conjunto de bibliotecas que varias aplicaciones flatpak comparten: una plataforma común sobre la que se apoyan, que se instala una vez y se actualiza por separado.

Es el término medio entre los dos modelos de la figura de la sección 9. La primera aplicación de GNOME arrastra su plataforma entera; la segunda, la tercera y la décima ya la encuentran instalada, y pesan lo que pesa la aplicación sola. El costo se paga una vez, pero se paga: es habitual que flatpak ocupe varios gigabytes con pocas aplicaciones, sobre todo si usan plataformas distintas.

Instalada, la aplicación se abre desde el menú, o desde la terminal con su identificador:

$ flatpak run org.gnome.Calculator &
$ flatpak list --app
Name          Application ID          Version  Branch  Installation
Calculator    org.gnome.Calculator    48.1     stable  system
$ flatpak list --runtime | wc -l
3

El & lanza la aplicación en segundo plano, como vimos en el tema 33, para no perder la terminal. A diferencia de snap, flatpak no agrega un comando corto a PATH: la forma de ejecutar es flatpak run con el identificador completo, y quien use mucho una aplicación desde la terminal puede crearle un alias.

Las actualizaciones no son automáticas desde la terminal: hay que ejecutar flatpak update, o dejar que lo haga la tienda gráfica del escritorio, que suele encargarse. Y como los runtimes quedan instalados cuando se quita la última aplicación que los usaba, flatpak uninstall --unused es el comando que recupera el espacio.

Para el sistema o para el usuario

La segunda columna es una posibilidad que ningún gestor de los anteriores ofrece: instalar una aplicación en una máquina donde no se tiene sudo. Los dos tipos de instalación son independientes, y el remoto también debe agregarse con --user para usar el segundo.

Permisos

Cada aplicación flatpak corre en un entorno aislado, y declara qué necesita de afuera. Se puede leer antes de confiar en ella:

$ flatpak info --show-permissions org.gnome.Calculator
[Context]
shared=network;ipc;
sockets=wayland;fallback-x11;
devices=dri;

Esta calculadora pide red, para las cotizaciones de monedas, pantalla y aceleración gráfica; no pide acceso a ningún archivo. Una línea filesystems=home significaría que puede leer y escribir todo tu directorio personal, y filesystems=host, casi todo el sistema: con permisos así, el aislamiento es más nominal que real, y conviene saberlo. Los permisos se pueden recortar o ampliar con flatpak override, o con la aplicación gráfica Flatseal. Los datos de cada aplicación quedan en ~/.var/app/identificador/.

12. AppImage

El tercer formato es el más simple de explicar: una AppImage es un archivo que es el programa. No hay gestor, ni tienda, ni instalación. Se descarga del sitio de quien lo hace, se le da permiso de ejecución y se lo ejecuta, con lo aprendido en el tema 18:

$ cd ~/Descargas
$ ls -l *.AppImage
-rw-rw-r-- 1 ana ana 98566328 oct 12 23:40 Programa-2.4.1-x86_64.AppImage
$ chmod +x Programa-2.4.1-x86_64.AppImage
$ ./Programa-2.4.1-x86_64.AppImage

Descargado del navegador, el archivo llega sin permiso de ejecución, por la umask que vimos entonces; de ahí el chmod. El ./ es el de siempre: el directorio actual no está en PATH.

Para quien use varias, el lugar natural es el ~/bin del tema 34, que ya está en PATH. Y en Ubuntu 24.04 muchas AppImage se niegan a arrancar con un error que menciona libfuse.so.2: les falta una biblioteca que la distribución ya no instala por defecto, y que se agrega con sudo apt install libfuse2t64.

13. De dónde instalar: un orden de preferencia

Con tantos caminos, la pregunta práctica es cuál tomar cuando un programa se ofrece por varios. No hay una regla única, pero sí un orden razonable, que va de lo más integrado y verificado a lo menos.

1. El repositorio de tu distribución. Si la versión que trae alcanza, es la opción: verificado, integrado, actualizado con el resto. apt, dnf, pacman
2. Un paquete universal de la tienda, cuando hace falta una versión más nueva o el programa no está en la distribución. Mejor si el editor está verificado. snap, flatpak
3. El repositorio o el paquete oficial de quien hace el programa, desde su propio sitio. .deb, .rpm, AppImage
4. Un repositorio de la comunidad, sabiendo de quién es. PPA, COPR, AUR
5. Un script de instalación descargado, solo si no hay otra manera, y después de leerlo. último recurso

Una clase aparte son los gestores de paquetes de los lenguajes de programación: pip para Python, npm para JavaScript, cargo para Rust, gem para Ruby. Instalan bibliotecas y herramientas de su lenguaje, y son asunto de los cursos de cada uno. Aquí interesa una sola regla, porque es fuente de sistemas rotos: no se usan con sudo. Instalar con sudo pip escribe en los mismos directorios que administra el gestor de la distribución, y pisa archivos de paquetes de los que dependen herramientas del sistema. Las distribuciones actuales lo impiden:

$ pip install requests
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.
…

El mensaje indica las salidas correctas: instalar la biblioteca como paquete de la distribución, sudo apt install python3-requests; o trabajar en un entorno virtual, que es una instalación de Python privada de un proyecto; o, si lo que se quiere es un programa y no una biblioteca, usar pipx. La que no hay que tomar es la opción que el mismo mensaje menciona al final para forzar la instalación.

Y queda, fuera de toda lista, el método original: descargar el código fuente y compilarlo. Lo que se instala así va a /usr/local, el directorio que el tema 8 reservó para lo que el gestor de paquetes no administra, justamente para que una cosa no pise la otra.

14. Recetas y errores comunes

La referencia del tema:

Si instalaste hello-world y la calculadora para practicar, puedes quitarlos con sudo snap remove hello-world y flatpak uninstall org.gnome.Calculator, seguido de flatpak uninstall --unused. Con esto sabemos poner programas en el sistema y sacarlos, en cualquier distribución. Lo que sigue del bloque es mirar el sistema mismo. En el tema 37 le preguntamos qué kernel ejecuta, cuánto hace que está encendido, cuánta memoria tiene libre y qué procesador lleva, con uname, uptime, free y lscpu.

15. Resumen

• Las distribuciones se agrupan en familias, y cada una tiene su formato de paquete y su gestor: .deb y apt en Debian, .rpm y dnf en Red Hat, pacman en Arch, zypper en SUSE, apk en Alpine.
• Los formatos no son intercambiables, pero los conceptos son los mismos: paquete, repositorio, dependencias y base de datos de lo instalado.
• /etc/os-release identifica la distribución con ID, y su familia con ID_LIKE.
• dnf usa subcomandos casi iguales a los de apt. Renueva la lista por su cuenta, update y upgrade son lo mismo, remove quita también las dependencias, y la confirmación tiene «no» por defecto.
• rpm -q consulta lo instalado: -qa lista todo, -ql los archivos de un paquete, -qf el paquete de un archivo.
• dnf history lista las operaciones y permite deshacerlas.
• pacman usa una letra mayúscula para la operación —-S repositorios, -Q lo instalado, -R quitar— y minúsculas que la modifican. pacman -Syu actualiza el sistema.
• Arch es de actualización continua: no tiene versiones, y no se debe instalar con -Sy sobre un sistema sin actualizar.
• Al traducir un tutorial cambia el comando y también, a menudo, el nombre del paquete.
• Un paquete universal incluye sus bibliotecas, funciona en cualquier distribución, se ejecuta aislado y se actualiza aparte. A cambio ocupa más y no comparte las correcciones.
• snap viene en Ubuntu, sirve también para programas de terminal, se actualiza solo y permite elegir canal y volver atrás con revert.
• flatpak es para aplicaciones gráficas, usa Flathub, identifica las aplicaciones como org.gnome.Calculator, comparte runtimes y puede instalar sin privilegios con --user.
• Una AppImage es un archivo ejecutable: se le da permiso con chmod +x y se ejecuta. No se actualiza ni está aislada.
• El orden de preferencia: el repositorio de la distribución, una tienda de paquetes universales, el paquete oficial del fabricante, un repositorio de la comunidad y, al final, un script.
• No se ejecuta con sudo un script sin leerlo, ni se usa sudo con pip y los demás gestores de lenguajes.

16. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Muestra /etc/os-release e identifica la distribución, la versión, el nombre en clave y la familia. Extrae solo el valor de VERSION_ID, sin las comillas, con grep y cut o con awk.
2. Averigua con type cuáles de estos gestores existen en tu sistema: apt, dnf, pacman, zypper, snap, flatpak.
3. Sin ejecutarlos, traduce a dnf y rpm, y a pacman, esta sesión de Ubuntu: sudo apt update && sudo apt upgrade; apt search htop; sudo apt install htop; dpkg -L htop; dpkg -S /usr/bin/htop; sudo apt purge htop.
4. Explica con palabras qué hace cada uno: pacman -Qi bash, pacman -Ql bash, pacman -Qdt, rpm -qc openssh-server, dnf provides '*/bin/dig'.
5. Ejecuta snap list. ¿Cuántos snaps hay, cuáles son de tipo base y quién publica cada uno? Comprueba con dpkg -l firefox si el paquete es de transición.
6. Con snap info, mira los canales de un snap instalado. ¿Qué versión hay en stable y cuál en edge? ¿Qué confinamiento tiene?
7. Instala hello-world con snap, ejecútalo y localízalo con type. Lista /snap/hello-world/ y ~/snap/. Quítalo con --purge, y revisa la operación con snap changes.
8. Si tienes entorno gráfico, instala flatpak, agrega Flathub e instala una aplicación pequeña. Anota cuánto descargó la primera, y cuánto una segunda del mismo escritorio. Lee los permisos de las dos.
9. Cuenta cuántos programas tienes por cada vía: paquetes pedidos expresamente con apt-mark showmanual, snaps que no sean base, y aplicaciones flatpak. ¿Hay alguno instalado por dos vías a la vez?
10. Busca en Internet las instrucciones de instalación de un programa que conozcas y que ofrezca varias vías. Ordénalas según la sección 13, y decide cuál usarías y por qué.