Guía completa para instalar paquetes DEB y RPM sin complicarte

Si vienes de Windows y acabas de aterrizar en Linux, es muy probable que te suenen raro los archivos .deb y .rpm. Son los equivalentes, a grandes rasgos, a los típicos .exe o .msi de Windows, pero adaptados al ecosistema de Linux y a cada familia de distribuciones. Y aunque muchos manuales tiran directamente de terminal y comandos, también es posible instalar paquetes deb y rpm sin volverte loco con la consola, combinando herramientas gráficas y algunos conceptos básicos.

Además, hay situaciones un poco más delicadas: por ejemplo, cuando te bajas un .deb antiguo de Microsoft Teams sin instrucciones claras, o cuando estás en una distro como Arch Linux y te encuentras con un .deb o un .rpm que, en teoría, esa distro ni siquiera usa. Vamos a ver de forma detallada qué es cada tipo de paquete, cómo se gestionan en las distintas familias de distribuciones y qué opciones tienes para manejarlos de la forma más cómoda posible, con y sin comandos, pero entendiendo lo que haces en todo momento.

Qué son los paquetes .deb y por qué son tan importantes

El formato .deb nació en Debian, y su nombre viene precisamente de acortar el de esta distro. Estos archivos son el sistema de empaquetado estándar en Debian y en todas las distribuciones basadas en ella, como Ubuntu, Linux Mint y muchas otras variantes. Si vienes de Windows, puedes pensar en los .deb como en los instaladores .exe, pero con una estructura interna mucho más controlada y estandarizada.

Un paquete .deb no es solo un archivo con el programa dentro, sino un contenedor que incluye todos los ficheros que se copiarán al sistema y una serie de scripts y metadatos para que la instalación y la configuración se hagan de forma ordenada. Esto permite que el sistema de paquetes sepa qué has instalado, qué dependencias necesita ese software, cómo actualizarlo y cómo desinstalarlo después.

Por dentro, un .deb se compone, como mínimo, de tres archivos clave que gestionan la información del paquete y sus datos. El primero es debian-binary, donde se indica la versión del formato de paquete (la última estable es la 2.0 en la mayoría de casos). El segundo es control.tar.gz, un archivo comprimido con toda la meta-información del paquete: nombre, versión, dependencias, scripts de instalación, etc. Y el tercero es data.tar (o variantes comprimidas como .gz, .bz2, .lzma), que contiene todos los archivos que se van a instalar realmente en tu sistema.

Además de esos componentes básicos, en la parte de control es habitual encontrarse ficheros como md5sums, donde se guardan las sumas de comprobación para verificar que los archivos no se han corrompido, o conffiles, que lista los archivos de configuración que no deben pisarse sin más durante una actualización. También hay varios scripts importantes: preinst, postinst, prerm y postrm, que se ejecutan antes o después de instalar o eliminar el paquete, así como un posible script config que se encarga de la configuración interactiva.

Todo esto convierte a los .deb en un formato bastante potente, pero no perfecto. Un límite muy habitual es que no siempre incluyen todas las dependencias necesarias para que el programa funcione. El paquete .deb puede exigir que en tu sistema ya estén instaladas ciertas librerías o componentes; si no lo están, la instalación fallará o el programa no se ejecutará correctamente. En esos casos, tocará instalar esas dependencias aparte, ya sea mediante el gestor de paquetes o, en entornos más complicados, manualmente.

Distribuciones como Debian, Ubuntu, Kubuntu, Lubuntu, Linux Mint y muchas otras basadas en ellas, usan .deb como formato por defecto. Incluso sistemas aparentemente alejados como iOS, en el mundo de Apple, se basan en un formato de paquete muy similar para gestionar sus aplicaciones, aunque la estructura interna no sea exactamente igual a la de los paquetes de Linux.

Cómo instalar archivos .deb en Linux con y sin comandos

En cualquier distro basada en Debian, el corazón de la gestión de paquetes .deb es la herramienta DPKG. Este programa se encarga de instalar, registrar y eliminar los paquetes desde el lado bajo nivel. Encima de DPKG se apoyan otras capas más amigables como APT o las interfaces gráficas, que facilitan muchísimo la vida a los usuarios que no quieren depender del terminal a cada paso.

En muchas distribuciones, especialmente Ubuntu y sus sabores, tienes disponibles interfaces gráficas como Synaptic, Gdebi, PackageKit o el propio Centro de software de Ubuntu. Estas aplicaciones permiten que instales paquetes .deb simplemente haciendo doble clic sobre el archivo descargado, de forma similar a como lo harías con un instalador en Windows, sin tener que escribir una sola línea en la consola.

Si quieres contar con estos gestores, puedes instalarlos desde los repositorios oficiales, normalmente con APT. Por ejemplo, es muy habitual usar Gdebi para abrir .deb descargados desde la web, ya que se encarga de resolver dependencias de forma más inteligente que DPKG puro y duro. Synaptic y PackageKit, por su parte, proporcionan una vista más global del sistema, permitiéndote buscar, instalar y eliminar paquetes con interfaz gráfica.

Una vez tienes descargado un archivo .deb desde la web de un desarrollador, GitHub o cualquier repositorio externo, la forma clásica de instalarlo sin volverte loco es simplemente abrirlo con el gestor de software de la distro: haces doble clic en el archivo .deb, se abre el instalador gráfico, revisas la información del paquete y pulsas en instalar. El sistema comprobará dependencias y, si falta algo, te avisará o intentará descargarlo automáticamente desde los repositorios.

Cuando la instalación termina con éxito, el programa aparece en el listado de aplicaciones de tu entorno de escritorio: en el menú de inicio, en el lanzador, en la búsqueda, etc. Si instalas, por ejemplo, un paquete .deb de un navegador o de Teams, deberías poder encontrarlo buscando su nombre como cualquier otra aplicación integrada en el sistema.

Instalar y gestionar .deb desde la terminal: DPKG y APT

Aunque el objetivo sea evitar depender de comandos para todo, conviene entender cómo lo gestiona la terminal porque muchas guías y documentación oficial los dan por supuestos. De hecho, incluso cuando usas herramientas gráficas, en segundo plano suelen estar tirando de DPKG y APT sin que tú lo veas.

El método más directo es usar dpkg -i paquete.deb, que instala el paquete local en el sistema. Este comando, a diferencia de APT, no se preocupa demasiado por buscar dependencias que falten: si el paquete requiere otros componentes que no tienes, mostrará errores y tendrás que resolverlos aparte, normalmente con APT o con otro gestor gráfico.

Para comprobar si un paquete concreto está instalado, puedes listar los paquetes que conoce dpkg con un filtro por nombre, usando una orden del estilo dpkg -l | grep ‘nombre’. Es una forma rápida de revisar si el sistema reconoce el paquete, qué versión tienes y si está marcado como instalado o eliminado pero con archivos de configuración aún presentes.

A la hora de desinstalar, DPKG permite dos enfoques: con la opción -r eliminas el paquete pero dejas los ficheros de configuración, mientras que con -P (purge) se borra todo rastro, incluyendo esos archivos de configuración que pueden quedar en /etc u otras rutas del sistema. Esta diferencia es útil si piensas reinstalar el programa manteniendo los ajustes o si quieres hacer limpieza total.

Por encima de dpkg funciona APT, el conocido gestor de paquetes usado en Debian, Ubuntu y derivados. APT se encarga de gestionar repositorios, dependencias y actualizaciones de una forma bastante más inteligente. Además de instalar programas desde los repos oficiales, también puede instalar archivos .deb locales que tengas en tu disco duro, resolviendo las dependencias automáticamente en la mayoría de casos.

Para ello, en lugar de llamar directamente a dpkg, se suele usar la sintaxis con ruta relativa al archivo, por ejemplo sudo apt install ./paquete.deb. El truco del «./» indica a APT que estás instalando un archivo local y no un paquete de los repositorios. APT, internamente, llamará a dpkg, pero añadirá su propia lógica para descargar e instalar las dependencias que falten desde los repos configurados.

Cuando quieras desinstalar un programa que instalaste desde un .deb local, ya no te hace falta tener el archivo original a mano. Basta con saber el nombre del paquete y usar sudo apt remove nombre-paquete para desinstalarlo conservando la configuración, o sudo apt purge nombre-paquete para borrar también los archivos de configuración que haya dejado por el sistema.

Paquetes .rpm: qué son y cómo encajan en este puzzle

El formato .rpm (Red Hat Package Manager) es el estándar en la familia de distribuciones basadas en Red Hat, como Red Hat Enterprise Linux, Fedora, openSUSE y otras derivadas. Igual que ocurre con los .deb en el mundo Debian, los .rpm contienen los archivos del programa, scripts y metadatos para gestionar instalaciones, actualizaciones y desinstalaciones dentro de esas distros.

De entrada, un paquete .rpm no es compatible de forma nativa con Ubuntu, Debian o Linux Mint, porque cada familia de distribuciones tiene su propio ecosistema de paquetes y herramientas. Sin embargo, en la práctica, más de una vez te encontrarás con software que solo ofrece un .rpm para Linux y no un .deb, sobre todo en proyectos enfocados a entornos empresariales basados en Red Hat.

Aunque Ubuntu y Debian no trabajan con .rpm de fábrica, existe la posibilidad de convertir esos paquetes .rpm en .deb y luego instalarlos como si fueran nativos. Esta conversión se hace con una herramienta veterana pero aún muy útil llamada Alien, que permite generar paquetes .deb a partir de .rpm (y otros formatos) o incluso instalar directamente el .rpm en sistemas basados en Debian.

No hay que perder de vista que, aunque el contenido funcional del programa sea el mismo, la conversión entre formatos puede traer consigo incompatibilidades de dependencias o de rutas. Por eso es recomendable recurrir a este método solo cuando no haya una versión nativa para tu distro y asumiendo que puede haber algún quebradero de cabeza adicional.

Desde la perspectiva contraria, también es posible convertir .deb en .rpm con Alien, lo que puede ser útil en distros del mundo Red Hat si un programa solo se distribuye en formato Debian. De nuevo, la compatibilidad no es garantizada al cien por cien, pero resuelve muchas situaciones en las que de otro modo tendrías que compilar el software desde el código fuente.

Cómo usar Alien para convertir e instalar paquetes RPM en Ubuntu y Debian

Si necesitas instalar un paquete .rpm en una distro basada en Debian, el primer paso suele ser asegurarte de tener acceso al repositorio Universe, que es donde se aloja Alien en sistemas como Ubuntu. Este repositorio extiende la oferta de software más allá de lo estrictamente oficial, incluyendo herramientas mantenidas por la comunidad.

En cuanto tengas activado ese repositorio y actualizada la lista de paquetes, podrás instalar Alien desde tu gestor de paquetes habitual. Una vez en tu sistema, Alien se convertirá en la navaja suiza para transformar .rpm en .deb con un solo comando, dejándote un archivo .deb equivalente listo para gestionar con DPKG, APT o incluso con un gestor gráfico tipo Gdebi.

El método más utilizado consiste en convertir el .rpm a .deb sin instalarlo directamente. Ejecutas Alien sobre el archivo .rpm y este genera un paquete .deb con un nombre similar en el mismo directorio en el que estás trabajando. Si estás en otra ruta distinta de la del archivo, tendrás que indicar la ruta completa del .rpm para que Alien lo encuentre.

Una vez tienes el .deb generado, lo tratas como cualquier otro paquete de Debian: puedes abrirlo con un gestor de software gráfico, instalarlo con dpkg -i o usar la aproximación más robusta de apt install ./archivo.deb para dejar que se encargue de las dependencias. De esta manera, integras en tu sistema un programa que originalmente solo estaba pensado para distros del mundo Red Hat.

Alien también ofrece la opción de instalar directamente el .rpm sin generar un .deb intermedio, usando un modo en el que él mismo realiza la conversión y lanza la instalación del tirón. Internamente sigue transformando el paquete, pero tú no ves el .deb resultante, sino que solo percibes el programa instalado. Aun así, muchos usuarios prefieren generar primero el .deb explícito para tener un poco más de control y poder conservarlo si necesitan reinstalarlo más adelante.

Otra forma de convertir RPM a DEB desde la terminal

Además del procedimiento típico en Ubuntu con Alien, hay escenarios donde se usa aptitude u otros gestores de paquetes para instalar Alien, sobre todo en entornos donde se prefiere ese gestor frente a APT clásico. El resultado final es el mismo: una vez Alien está disponible, se convierte en la herramienta central para traducir entre formatos RPM y DEB.

El flujo habitual consiste en descargar primero el archivo .rpm que quieres utilizar, colocarlo en una ruta conocida del sistema y lanzar Alien contra él. Tras la conversión, se crea en la misma carpeta un archivo .deb que replica el contenido y los metadatos del original en la medida de lo posible, listo para ser tratado como un paquete nativo de Debian.

Una vez generado el archivo .deb, lo normal en sistemas sin interfaz gráfica es instalarlo mediante dpkg -i nombre-paquete.deb, confiando en que las dependencias necesarias ya estén presentes o se puedan instalar aparte. En sistemas de escritorio, en cambio, suele ser mucho más cómodo abrir ese .deb recién creado con el centro de software o con Gdebi, de forma que el usuario no tenga que retener comandos ni rutas en la cabeza.

Este enfoque de convertir primero y luego instalar permite repetir la instalación cuantas veces necesites, ya que te quedas con el paquete .deb como «copia local» adaptada a tu familia de distribución. Es especialmente útil si trabajas con varios equipos similares y quieres desplegar el mismo software sin depender siempre de la versión .rpm original.

Conviene recordar, en cualquier caso, que cuando recurres a Alien estás saliendo un poco del camino «oficial», así que conviene revisar los mensajes de error y comprobar si el programa responde bien tras la instalación. En algunos casos, puede que falten librerías o haya diferencias de versiones respecto a las distros para las que el .rpm fue diseñado originalmente.

Arch Linux: qué hacer con los .deb y .rpm y qué tiendas de software usar

Si estás usando Arch Linux y te descargas un .deb o un .rpm, la primera reacción suele ser de desconcierto, porque Arch no utiliza ninguno de esos formatos. Aquí el sistema de paquetes se basa en el gestor pacman y en paquetes con extensión .pkg.tar.zst preparados específicamente para Arch y sus derivados como Manjaro.

Instalar directamente un archivo .deb o .rpm en Arch no es la opción recomendada, porque la filosofía de la distro es otra y las rutas, las librerías y las versiones no siempre coinciden con las de Debian o Red Hat. Lo más sensato es buscar siempre si el software que te interesa está disponible en los repositorios oficiales de Arch o en el popular AUR (Arch User Repository), donde la comunidad mantiene recetas de compilación (PKGBUILDs) para una enorme cantidad de programas.

Existen herramientas y scripts capaces de convertir .deb o .rpm a paquetes para Arch, o de instalarlos de forma algo forzada, pero no es la vía más robusta ni la que recomiendan los propios mantenedores de la distribución. En general, es mejor encontrar un PKGBUILD en AUR para ese programa o usar alternativas empaquetadas como Flatpak o Snap si necesitas algo que no está en los repos oficiales.

En cuanto a tiendas de software con interfaz gráfica, Arch y sus derivadas cuentan con varias opciones. Una de las más conocidas es Pamac (muy usado en Manjaro), que te permite gestionar paquetes y AUR desde una ventana muy similar a las tiendas de aplicaciones en Ubuntu. También hay frontends gráficos para pacman como Octopi y otras herramientas que dan una experiencia de tienda de software bastante amigable.

Gracias a estas interfaces, puedes buscar, instalar y actualizar aplicaciones sin necesidad de escribir comandos, todo gestionado a través del ecosistema nativo de Arch en lugar de depender de .deb o .rpm. Esto encaja mejor con la filosofía rolling release de la distro y reduce problemas de compatibilidad que pueden surgir al querer meter paquetes pensados para otras familias.

Dónde descargar archivos .deb y .rpm de forma segura

Si con los buscadores habituales de tu distro no encuentras el programa que buscas, siempre queda la opción de acudir a distintas fuentes de descarga de paquetes en Internet. Eso sí, conviene ser muy selectivo y priorizar sitios fiables para minimizar riesgos de seguridad y de paquetes manipulados.

El primer lugar al que deberías mirar casi siempre es la web oficial del desarrollador del programa. La mayoría de proyectos ofrecen en su propia página los enlaces de descarga de las últimas versiones, tanto en formato .deb y .rpm como en otros empaquetados. Además, suelen incluir instrucciones específicas para cada distribución o, como mínimo, una sección de instalación que te orienta sobre qué archivo elegir.

Si trabajas con Debian o derivadas, también puedes acudir a la página oficial de paquetes de Debian, que ofrece búsquedas avanzadas en un catálogo enorme de software en formato .deb. Una ventaja aquí es que buena parte del contenido está disponible en español, algo que viene muy bien si no te manejas demasiado con documentación en inglés.

Existen buscadores especializados en paquetes, como RPM Seek, que aunque lleva «RPM» en el nombre también ofrece resultados en formato .deb. Permite filtrar por distribución, arquitectura y versión, facilitando encontrar justo el paquete que necesitas y, en muchos casos, dándote también pistas sobre las dependencias necesarias para hacerlo funcionar.

Otro sitio veterano es RPM PBone Search, que ofrece un buscador muy avanzado centrado en paquetes .rpm pero que también cubre en buena medida los .deb. Su valor añadido está en que te ayuda a identificar qué librerías o paquetes adicionales pueden hacer falta, lo que resulta muy útil si estás depurando problemas de dependencias.

En el mundo del código abierto, plataformas como GitHub o GitLab son también una mina de oro. Muchos desarrolladores suben directamente los instaladores .deb y .rpm a la sección de «Releases» de sus proyectos, con versiones etiquetadas para distintas arquitecturas (amd64, arm64, etc.). Desde ahí, puedes descargar el paquete correspondiente y abrirlo con tu gestor habitual de software sin mayor complicación.

Versiones estables, inestables y de prueba: qué implica para tus DEB

Cuando accedes a sitios oficiales como la página de paquetes de Debian, suele haber más de una rama disponible: estable, inestable y de pruebas. La estable es la que se recomienda para la mayoría de usuarios, ya que prioriza la fiabilidad y la seguridad por encima de tener siempre la última versión de cada programa.

Las versiones inestables o de prueba resultan muy atractivas si te gusta ir un paso por delante y probar novedades antes de que lleguen a todo el mundo. Sin embargo, tienen la desventaja de que los paquetes pueden incluir fallos, comportamientos poco pulidos o incluso carencias de actualización automática, lo que obliga a estar algo más pendiente del mantenimiento manual.

Usar paquetes .deb procedentes de ramas inestables puede darte acceso a funciones aún no disponibles en la rama estable, pero también implica que, en algunos casos, el paquete falle en la instalación o dé problemas en tiempo de ejecución. Además, es más probable que aparezcan conflictos de dependencias si mezclas muchos paquetes experimentales con un sistema pensado para ser estable.

Si te animas a usar estas ramas, conviene hacerlo con cierta prudencia y, a ser posible, en entornos de prueba o máquinas donde no te juegas datos críticos. Así podrás disfrutar de las novedades sin que un fallo puntual te deje tirado en un entorno de producción o de trabajo diario.

En cualquier caso, cuando vayas a descargar un archivo .deb desde repositorios que ofrecen varias ramas, fíjate bien en para qué versión de la distro está pensado, qué rama ocupa y si existen avisos de posibles problemas funcionales o de seguridad asociados a ese paquete concreto.

Cómo se actualizan los programas instalados desde paquetes .deb

El modo de actualizar un programa instalado desde un archivo .deb puede variar bastante dependiendo de cómo lo haya empaquetado el desarrollador. Hay aplicaciones, como Google Chrome o Discord, que una vez instaladas se integran en tus repositorios o traen su propia mecánica de autoactualización, de modo que no tienes que preocuparte de ir descargando nuevos .deb a mano.

En estos casos, mientras tengas acceso a Internet y el repositorio correspondiente esté activo, las nuevas versiones llegan a través de tu sistema habitual de actualizaciones, ya sea mediante APT, la herramienta gráfica de tu distro o los propios mecanismos internos de la aplicación. Es una forma muy cómoda de mantenerte al día sin enterarte siquiera del proceso.

Sin embargo, hay muchos otros programas empaquetados en .deb que no disponen de autoactualización ni añaden un repositorio propio al sistema. En esos escenarios, la única forma de poner al día el software es entrar de nuevo en la página de descargas del proyecto cuando salga una versión más reciente, bajar el nuevo .deb e instalarlo igual que hiciste la primera vez.

Generalmente, al instalar un .deb más nuevo sobre una versión anterior, el sistema sustituye la versión vieja por la nueva sin dejar duplicados, aunque siempre es buena idea comprobar que el gestor de paquetes lo interpreta correctamente. En la mayoría de distros, no tendrás que desinstalar antes la versión previa: con instalar el paquete actualizado suele bastar.

Este proceso manual implica que seas tú quien controle el calendario de actualizaciones, por lo que no deberías olvidarte de revisar periódicamente si hay nuevas versiones, sobre todo cuando se trata de aplicaciones que pueden verse afectadas por fallos de seguridad o que utilices a diario para tareas críticas como navegación web o comunicaciones.

Alternativas modernas a los paquetes DEB y RPM en Linux

Aunque los formatos .deb y .rpm siguen siendo el estándar en gran parte del ecosistema Linux, en los últimos años han ido ganando terreno otras formas de empaquetar aplicaciones. Estas alternativas buscan resolver problemas clásicos, como la gestión de dependencias o el aislamiento de aplicaciones, ofreciendo paquetes más autosuficientes y fáciles de mantener.

Una de las alternativas de toda la vida son los archivos .tar.gz, donde en muchos casos lo que descargas es el código fuente del programa para compilarlo tú mismo. Este enfoque ofrece un control muy fino sobre lo que instalas, pero exige más conocimientos y tiempo, razón por la que no suele ser la opción favorita de los usuarios que prefieren métodos sencillos y rápidos.

En el terreno de los formatos modernos, han aparecido empaquetados como Snap y Flatpak, que incluyen en su interior el programa y todas (o casi todas) sus dependencias. Esto significa que el software suele funcionar igual en distintas distribuciones siempre que tengan soporte para estos formatos, reduciendo los típicos errores por bibliotecas que faltan o versiones incompatibles.

Los paquetes Snap fueron impulsados por Canonical, la empresa detrás de Ubuntu, con la idea de convertirse en una especie de sucesor del .deb. Un Snap es básicamente un contenedor de aplicación con todo lo que necesita para ejecutarse, lo que minimiza los problemas de dependencias rotas. Además, se ejecuta en un entorno relativamente aislado del resto del sistema, lo que mejora la seguridad y evita que interfiera demasiado con otros programas.

Por otro lado, los Flatpak proponen algo muy similar, pero con un enfoque más abierto y menos centralizado que Snap, lo que los ha hecho bastante populares en muchas distribuciones. Al igual que estos, se ejecutan dentro de un sandbox y ofrecen una gran portabilidad entre distros siempre que estas tengan Flatpak habilitado, con tiendas gráficas como Flathub ofreciendo un catálogo cada vez más amplio.

Aun con todas estas opciones, el sistema de repositorios clásicos con APT, pacman o yum/dnf sigue siendo fundamental: es la forma principal de buscar, descargar e instalar software en la mayoría de distros, además de mantenerlo actualizado de forma coherente con el resto del sistema. Lo que hacen Snap y Flatpak es complementar esa base, no sustituirla por completo.

Todo este panorama deja los .deb y .rpm en un papel aún muy relevante, sobre todo para integración profunda con el sistema y para software tradicional, pero también abre la puerta a formatos más flexibles y herméticos que facilitan distribuir aplicaciones sin tantas fricciones entre distintas familias de Linux.

Con todo lo que hemos visto, queda claro que los paquetes .deb y .rpm son el núcleo de la distribución de software en buena parte del ecosistema Linux, pero también que existen herramientas, como Alien, APT, gestores gráficos y sistemas alternativos como Snap o Flatpak, que permiten instalarlos y gestionarlos sin necesidad de pelearse constantemente con la terminal; entender mínimamente cómo funcionan estos formatos, de dónde descargarlos con seguridad y qué límites tienen frente a nuevas opciones ayuda a tomar mejores decisiones a la hora de instalar aplicaciones, ya sea en Ubuntu, Debian, Arch o cualquier otra distro que tengas entre manos.