2.7.1. Gestión del software

La mayor parte del software del que se constituyen los sistemas linux es software libre, disponible en la red, de ahí que las distribuciones se encarguen de seleccionarlo, adaptarlo y facilitarlo. Por ello, Debian dispone de un sistema de paquetes .deb que facilita la instalación, actualización y borrado del software.

En general, la instalación de software en un sistema Linux puede hacerse por distintas vías:

  1. Paquetería propia:

    El sistema de paquetes proporcionado por la distribución debe ser la vía preferente, puesto que asegura la integración y compatibilidad de la aplicación con el resto del sistema, minimiza la duplicidad de software intermedio (librerías) y permite una cómoda actualización.

  2. Paquetería universal:

    Existen varias alternativas que proveen a Linux de un sistema de paquetes independiente de la distribución. Estos sistemas se basan en proveer todas las dependencias necesarias para las aplicaciones sin tener en cuenta el software ya instalado a través de la paquetería propia de la distribución; y realizan la instalación de todos los archivos necesarios en un lugar de disco que no interfiera con ella. Proporcionan la posibilidad de gestionar los paquetes instalados y las actualizaciones, por lo que son relativamente cómodos, aunque tiene varios inconvenientes respecto a los paquetes de la distribución:

    • Menor integración con el sistema.

    • Duplicidad de librerías, ya que no utilizarán las ya instaladas en el sistema de manera regular (a través del sistema de paquetes de la distribución).

    Pese a ello son una excelente alternativa si:

    • La distribución no dispone del paquete (improbable si la distribución es de las mayoritarias).

    • Necesitamos una versión de la aplicación distinta de la que ofrece la distribución. Por ejemplo, una nueva versión que aún no haya sido portada al sistema de paqueteas[1].

    • La distribución carece de las dependencias adecuadas. Por ejemplo, una aplicación aún escrita en Python2 para la que ya no habrá soporte en las distribuciones modernas que han migrado ya todas a Python3.

    Hay varias alternativas:

    • Flatpak, promovida por freedesktop.org. Sus paquetes comparten una base común de bibliotecas principales, por lo que es costoso en espacio instalar el primer paquete, pero no tanto los demás.

    • Snap, promovida por Canonical, la empresa detrás de Ubuntu. No dispone de esa base común, de manera que tiende a incluir todas sus dependencias dentro del paquete. El principal problema de esta alternativa es que Canonical controla el repositorio del que se descargan los paquetes de Snap y resulta imposible que terceros creen repositorios alternativos, lo que convierte a esta paquetería en un monopolio de Canonical que puede hacer y deshacer a su antojo (como Google puede hacerlo en la Play Store o Apple en la Apple Store).

    • AppImage, que desarrolla el mismo concepto que los bundle de MacOS: el archivo contiene todas las dependencias necesarias para que se ejecute la aplicación y no se instala: al ejecutarlo se monta su contenido y arranca el programa. Eliminar la aplicación consiste básicamente en eliminar el archivo.

    • Docker, que no es propiamente una solución para instalar software, sino que desarrolla el concepto de contenedor de aplicación, pero que puede utilizarse puntualmente para tal fin. Por ejemplo, este contenedor permite utilizar Gimp a través del navegador.

    Ver también

    Échele un vistado al artículo AppImage, Snap Y Flatpak…. ¿todos o ninguno? que desarrolla las características de estos tres gestores universales de paquetes.

  3. Instalación manual:

    Si no hay oportunidad de usar ninguna de las dos vías anteriores, sólo será posible instalar la aplicación de modo manual. Este vía sólo puede ser el último recurso, porque no sólo es la que presenta una instalación más complicada, sino también una mantenimiento y actualización manual, lo que la vuelve engorrosa y fuertemente desaconsejable.

    Nota

    El software privativo por lo general es instalable por esta vía, aunque a veces, si es gratuito, se nos ofrece un repositorio de alguna de las dos vías anteriores.

    La casuística de esta tercera vía es muy grande:

    • En ocasiones, se nos ofrecen en forma de paquete del sistema propio de paquetería que utiliza nuestro sistema o de un sistema universal de paquetería. Esta es la fórmula más sencilla para la instalación, aunque puede estar sujeta a incompatibilidades (fallos de dependencias como ya entenderemos) y se carecerá de actualización a través del gestor de paquetes.

      Nota

      Cuando se nos ofrece, no un paquete aislado de software, sino un repositorio del que obtener el paquete, estamos ante una situación intermedia entre uno de los dos y éste; ya que la instalación no es manual y el repositorio puede estar siendo mantenido por alguien que se encarga de actualizarlo periódicamente, pero a la vez no tenemos garantía de que estas actualización estén sincronizadas con el ritmo de actualización del sistema de paquetería. Para entender todo esto deberá completar la lectura sobre los sistemas de paquetes incluida más abajo.`

    • Se proporciona un archivo que, mediante un script de instalación, instala la aplicación en el sistema. Esto presenta todos los inconvenientes posibles:

      • Puede haber incompatibilidad de dependencias.

      • No controlaremos la instalación, puesto que ningún gestor de software será capaz de detectar que la aplicación está instalada y, por supuesto, tampoco será capaz de desinstalarla. Afortunadamente, estos archivos suelen proporcionar también un script de desinstalación.

      • El mantenimiento y actualización debe ser manual.

    • Finalmente, también puede darse el caso de que de la aplicación sólo se proprocione el código fuente y tengamos que ser nosotros mismos los que la compilemos leyendo la documentación. Es la instalación más ardua porque este paso no siempre es trivial y, además, una vez completado nos encontraremos en uno de los dos casos anteriores (paquete aislado o script de instalación)

Los sistemas de paquetes

El software tanto el propio como el universal se basa en el concepto de sistema de paquetes que conviene tener claro antes de proseguir.

Sistema de paquetes (o sistema de paquetería)

Es un conjunto de aplicaciones, organizadas en paquetes y accesibves a través de servidores, que se estructuran de modo que se facilite su instalación, mantenimiento y actualización.

Paquete

Es una colección de archivos binarios, de documentación o de configuración relacionados entre sí por constituir una aplicación o parte de una aplicación. Existen distintos formatos de paquete. El propio de Debian y todas sus distribuciones derivadas es .deb[2].

Repositorio o réplica

Es un lugar (cdrom, servidor web, servidor FTP) donde se almacenan paquetes, con el propósito de hacerlos accesibles a los sistemas clientes y que estos puedan, de modo sencillo, descargarlos e instalarlos o actualizarlos.

Gestor de paquetes

Es el sotfware encargado de gestionar la instalación, eliminación, actualización y mantenimiento de los paquetes.

Tanto a la paquetería propia (de la distribución) como la paquetería universal se le pueden aplicar estos conceptos. Hay, sin embargo, una diferencia importante de una respecto a la otra: mientras que la paquetería universal se instala de modo que no interfiera con el resto del sistema, la paquetería de la distribución lo hará ocupando los directorios que se espera que ocupen los archivos dependiendo de su naturaleza (p.e. un ejecutable se instalará en /usr/bin/, por ejemplo. Esto supone que no pueda haber en un mismo sistema paqueterías de distribución (p.e. que intentemos compaginar el sistema de paquetes de Debian con el de Red Hat), en cambio sí es posible compaginar el sistema de paquetes de nuestra distribución y uno o más sistemas de paquetes universales.

Por último, es importante tener claro que los paquetes no son independientes unos de otros, sino que establece una compleja relación de dependencias entre ellos, ya que se empaqueta las dependencias (librerías, por ejemplo) en paquetes separados de los paquetes de aplicación final a fin de que las dependencias no se instalen duplicadas. De este modo, los dos paquetes de sendas aplicaciones finales, que dependan de una misma librería, no requerirán incluir dicha librería dentro de sí, sino únicamente una dependencia al paquete que instala la librería. Esto elimina, pues, duplicidades, pero introduce relaciones entre los distintos paquetes y provoca que el sistema de paquetes evoluciones como un conjunto. Así, la actualización a una nueva versión de esa librería, provocará que los paquetes de esas dos aplicaciones finales relacionadas también se actualicen.

Gestores de paquetes

Descontada la última vía manual, la instalación y mantenimiento de software se basa en paquetes para los cuales cada sistema proporciona el suyo. Trataremos este concepto más adelante, pero ahora es preciso recalcar que existen:

Gestores

propiamente dichos, que son aquellos que gestionan un sistema de paquetes concreto. Por ejemplo, APT que gestiona el sistema de paquetes de Debian o flatpak, que gestiona el sistema homónimo de paquetes universales.

Multigestores (terminología propia)

que son aquellos capaces de interactuar con distintos sistemas de paquetes, de manera que propocionan una única interfaz de usuario, sea cual sea el sistema de paquetes que se use como backend.

Nota

Esta posibilidad es debida a que el proyecto freedesktop.org ha definido un estándar de interoperatividad para los sistemas de paquetes y una librería (AppStream) que lo implementa, por lo que cualquier sistema que lo cumpla es susceptible de poder ser manejado por uno de estos multigestores.

Por otra parte, ya dejamos establecido que en un mismo sistema podemos conjugar varios sistemas de paquetes (siempre que haya un sólo sistema propio de distribución). A los multigestores capaces de compatibilizar la gestión de varios sistemas de paquetería los llamaremos agregadores (terminología también propia). Los multigestores más conocidos son:

  • PackageKit, independiente del entorno de escritorio e incluso con interfaz CLI. Soporta únicamente algunos sistemas de paquetes de distribución y, por tanto, no es un agregador. Aunque puede ser utilizado directamente, proporciona una API para que los entornos de escritorio puedan construir aplicaciones gráficas de gestión de paquetes.

  • Gnome Software, agregador para el escritorio Gnome, que permite compatibilizar los paquetes de Snap y Flatpak con los de la distribución en la que se instale. Otros agregadores semejantes como Ubuntu Software o el Centro de Guadalinex son simples derivados de éste.

  • Discover, agregador con las mismas posibilidades que Gnome Software, pero para el escritorio KDE.

Todos estos multigestores se caracterizan por abstraer aún más a los usuarios del propio sistema de empaquetado y, aunque traten con paquetes de distribución, sólo muestran los paquetes de aplicación final, adquiriendo así la apariencia de una «tienda de aplicaciones» al modo de las que hay en Windows, Android o iOS.

Nota

Tanto Discover como Gnome Software usan internamente la API de PackageKit para manejar los paquetes de distribución.

2.7.1.1. Paquetería propia

Advertencia

Este apartado es hasta tal punto dependiente de la distribución que es absolutamente inútil su lectura si no se utiliza una distribución basada en Debian.

2.7.1.1.1. Ramas

Advertencia

Este subapartado, en concreto, es específico para Debian Si se utiliza una distribución basada en Debian, pero no Debian misma, sáltelo sin escrúpulo.

Debian está dividida en tres grandes ramas:

  1. La distribución estable (stable) orientada al uso en servidores, durante cuya vida sólo recibe actualizaciones para correción de bugs y problemas de seguridad.

  2. La distribución en pruebas (testing), que se actualiza regularmente con nuevo software y versiones más recientes del software ya existente. Conceptualmente, es una distribución rolling.

  3. La distribución inestable (unstable), que se actualiza aún con mayor celeridad y que sirve como alimentación a la rama en pruebas.

Por tradición[3], las diferentes versiones de Debian reciben el nombre de un personaje de la serie de películas de animación Toy Story. La actual estable, la versión 8[4], tiene por nombre Jessie; la de pruebas, Stretch; y la inestable es la única que no cambia su nombre y se llama siempre Sid (el chico que rompía los juguetes).

El ciclo de vida es el siguiente:

  1. La distribución inestable recibe constantemente paquetes con las últimas versiones de software.

  2. También constantemente, la rama en pruebas va recibiendo paquetes procedentes de la rama inestable, según se vea que no producen errores graves en el sistema.

  3. La rama estable, ajena a todas estas actualizaciones, mantiene las versiones de los paquetes con la que salió. Sólo recibe actualizaciones que corrijan problemas detectados.

  4. En un momento determinado (últimamente es cada dos años), se congela la rama en pruebas, de manera que deja de recibir actualizaciones de paquetes procedentes de sid y el equipo de desarrollo se centra en la tarea de eliminar bugs importantes. Este proceso es lento y suele llevar más de seis meses.

  5. Cuando no existen errores graves detectados, la rama estable pasa a ser la vieja estable (oldstable), y la rama en pruebas congelada se desdobla de manera que, por un lado, pasa a ser la estable, llevándose el nombre consigo; y, por otro, se rebautiza con un nuevo personaje de Toy Story y comienza de nuevo a admitir actualizaciones procedentes de sid.

  6. Por su parte, la vieja inestable sigue recibiendo soporte oficial de Debian durante al menos tres años más, de manera que se llegue al menos a los cinco años de vida: los dos que tuvo como distribución estable y estos tres años adicionales de soporte.

Además de las tres distribuciones de desarrollo principales, existen otras tres de interés:

  1. La vieja estable (oldstable) que ya se ha explicado.

  2. La experimental, que no es una distribución completa, sino un repositorio de pruebas donde se sube software nuevo o versiones nuevas de software existente y que, por lo general, o no funciona o no lo hace totalmente, pero se incluye como paso previo a poder entrar en la distribución inestable.

  3. Los backports para la versión estable, que es un repositorio con software más moderno que aquel del que se dispone en la estable. Tengamos en cuenta que entre la fase de congelación y el tiempo que tenga ya como estable, nos podemos encontrar con software que tiene casi tres años de antigüedad. Obviamente, la estabilidad y seguridad de los paquetes de la backports no es comparable con la de aquellos que se encuentran en la estable, así que el administrador debe sopesar si elige actualizar a versiones más modernas corriendo el riesgo de encontrar bugs adicionales.

Por otro lado, a causa de su licencia, dentro de una distribución los paquetes se distribuyen en tres componentes o secciones:

main

Paquetes que cumplen los requisitos para ser considerados por Debian software libre y que, además, sólo tienen dependencia de paquetes que también pertenecen a este componente.

contrib

Paquetes que son software libre, pero tiene dependencia de paquetes que no son software libre.

non-free

Paquetes que no son software libre a criterio de Debian.

Nota

Las instalaciones de Debian suelen incluir por defecto sólo el componente main, aunque podemos añadir los otros dos posteriormente sin problemas.

2.7.1.1.2. Gestores

Para el control de paquetes, Debian dispone de varias herramientas:

dpkg

No es propiamente un gestor, sino la herramienta básica para la instalación, borrado y actualización de un paquete y, consecuentemente, es utilizada por los gestores de los que se hablará a continuación.

apt-*

Familia de órdenes (apt-get, apt-cache) que gestiona paquetes desde la línea de comandos. Fue durante mucho tiempo el gestor más usado.

apt

La familia anterior tiene el inconveniente de que, dependiendo de la operación que queramos realizar, debemos usar uno u otro comando (apt-get, apt-cache). Para paliar esto, se creó la orden apt a secas que reúne las operaciones más habituales. Modernamente, es la herramienta recomendada.

dselect

Fue el primer front-end para la gestión de paquetes. Apenas se usa ya.

aptitude

Como dselect provee de una interfaz para la gestión de paquetes, aunque la mayor parte de los usuarios lo utilice pasando directamente las opciones necesarias a través de la línea de comandos. De esta última forma, tiene muchas similitudes con apt-get. Tiene como ventaja sobre este último que es capaz de hacer sugerencias, cuando por algún problema de incompatibilidades no es posible instalar algún paquete o actualizar el sistema completo.

A partir de Stretch no viene instalado de serie.

synaptic

Gestor gráfico de paquetes no ligado a un escritorio concreto.

En el manual basaremos las explicaciones en apt, aunque daremos también las explicaciones de cómo gestionar con la antigua familia apt-*.

2.7.1.1.3. Repositorios

Antes de realizar cualquier operación sobre paquetes es importante cerciorarse de cómo se obtendrán. Lo habitual es que éstos se obtengan de internet, lo que exige tener definidos los repositorios en el archivo /etc/apt/sources.list. Un contenido típico es el siguiente:

# /etc/apt/sources.list

deb http://ftp.cica.es/debian/ stretch main contrib non-free
# deb-src http://ftp.cica.es/debian/ stretch main

deb http://security.debian.org/debian-security stretch/updates main
# deb-src http://security.debian.org/debian-security stretch/updates main

Cada línea del archivo representa una fuente de obtención de paquetes y su sintaxis es la siguiente:

deb|deb-src URL distribución componente1 [componente2 [componente3]]

En particular, el significado de cada campo es el siguiente.

  1. Las línea que empiezan por deb representan fuentes para paquetes compilados, mientras que las líneas que empiezan por deb-src, fuentes para paquetes de código fuente que necesitan compilarse. Por lo general, los paquetes compilados tienen un correspondiente sin compilar por si deseamos hacer esta operación nosotros mismos. No es lo habitual y, de hecho, en el ejemplo, están comentadas las líneas (anteponiendo en ellas una almohadilla) para que no tengan efecto.

  2. La URL indica la dirección del repositorio. Hay muchísimos repartidos por todo el mundo. La lista completa puede obtenerse de la página de Debian.

  3. En el campo referente a la distribución puede incluirse o el nombre de la distribución (el personaje de Toy Story) o el nombre de la rama (oldstable, stable, testing, unstable, experimental, etc.)[5]

  4. El componente hace referencia a main, contrib o non-free. Lo habitual es tener main, que contiene el grueso de los paquetes, y de forma accesoria contrib y non-free.

Advertencia

Si se hizo una instalación a partir de un cdrom, es muy probable que el propio cdrom esté incluido como fuente. Es más que recomendable eliminar la línea (o comentarla) para evitar el tedio de soportar que el gestor nos pida el cdrom.

Además de este archivo, puedes crearse otros .list dentro de /etc/apt/sources.list.d con repositorios más específicos.

Advertencia

No es buena idea mezclar distintas ramas (testing, sid) en un mismo sistema a menos que se haga con cuidado, lo cual implica hacer uso del apt-pinning.

2.7.1.1.4. Operaciones básicas

Cerciorados de que se dispone de un repositorio válido, la primera acción es bajar la lista de paquetes disponibles o actualizarla si ya se realizó antes la operación:

# apt update

Esto se debe a que, apt usa para la gestión de paquetes una copia de la lista del paquetes disponibles no la lista de paquetes propiamente contenida en el repositorio. La operación es recomendable hacerla siempre antes de instalar un paquete (a menos de que se acabe de instalar otro antes), ya que desde la última obtención de la lista, los paquetes disponibles en el repositorio han podido cambiar.

Advertencia

La acción anterior no actualiza el sistema, sólo la lista de paquetes disponibles.

Actualizada la lista, es posible instalar un paquete individual o actualizar los paquetes a su versión más reciente. Esta última acción tiene dos variables:

# apt upgrade

que hace una actualización no traumática, es decir, sólo realiza las actualizaciones que no implican un cambio significativo en la composición de nuestros paquetes instalados. Estos cambios significativos pueden deberse al hecho de que le mantenedor de una aplicación haya decidido restructurar los paquetes relacionados con ella, de manera que una actualización implique borrar paquetes. Como consecuencia, pueden quedar paquetes retenidos sin actualizar. La variante que provoca una actualización completa[6] es:

# apt dist-upgrade

Si nuestra intención es instalar software, por ejemplo, el paquete pv:

# apt install pv

Para desinstalar existen dos posibilidades:

  1. Hacerlo de modo que no se eliminen los archivos de configuración:

    # apt remove pv

  2. Hacerlo sin que quede rastro de ellos:

    # apt purge pv

También es posible instalar y desinstalar en una misma acción añadiendo los signos + o - tras el nombre del paquete:

#. apt install vim+ vim-tiny-

Cuando un paquete se instala, es común que dependa de otros paquetes que no están instalados y, como consecuencia que el sistema, se vea obligado a instalar más de un paquete. En este caso, apt nos informará y nos pedirá que confirmemos la operación. Si deseamos responder sí automáticamente, basta con incluir la opción -y:

# apt install -y vim+ vim-tiny-

Del mismo modo, al desinstalar un paquete es posible que paquetes que se instalaron solamente para satisfacer las dependencias de éste, queden sin razón de ser en el sistema. Esto es conocido por el gestor porque cuando instala un paquete lo marca como instalado manualmente o instalado automáticamente.

Por último, apt install permite también instalar paquetes .deb descargados previamente[7]. En este caso, para que la herramienta distinga un archivo de un paquete de repositorio, es necesario que en al expresar el archivo se incluya una ruta absoluta o relativa:

# apt install /tmp/AutoFirma_1_6_5.deb
# apt install ./AutoFirma_1_6_5.deb

Cuando se hacen operaciones de borrado (remove) y purga (purge), pero también de actualización (upgrade) o, incluso, de instalación (install), puede ocurrir que resulten paquetes huérfanos, esto es, paquetes instalados automáticamente, pero que ya no son necesarios puesto que ningún paquete que requiera de su presencia, está ya instalado. En este caso, existe un comando específico para eliminarlos (que se nos sugerirá cuando el sistema detecte su presencia):

# apt autoremove

Sin embargo, podemos ahorrarnos esta operación si incluímos la opción --autoremove en cualquira de las operaciones anteriormente referidas (install, remove, upgrade o purge):

# apt --autoremove remove nginx

Cuando se instala (install) o se actualiza el sistema (upgrade, dist-upgrade), se van descargando los paquetes necesarios y almacenando dentro de /var/cache/apt/archives. Esa es la razón por la que si cancelamos la orden y la proseguimos después, seguirá la descarga en el punto en que quedó.

Advertencia

Antes de instalar o actualizar es muy, muy conveniente actualizar la lista de paquetes, porque podemos tenerla obsoleta y que los paquetes existentes en el repositorio no sean los mismos que nuestro sistema cree. De hecho, si intentamos instalar un paquete y el sistema nos informa de que éste no existe, supuesto que tengamos bien la conexión a internet, la razón casi segura es que estamos trabajando con una lista obsoleta y haya que actualizarla.

Nota

Dado que que conveniente actualizar la lista antes de instalar es muy común escribir líneas como esta:

# apt update && apt install -y pv

Para buscar paquetes adecuados para una determinada tarea son útiles dos comandos:

$ apt search términos de búsqueda

que nos devolverá los paquetes relacionados con los términos de búsqueda que se incluyan. Y cuando se duda si instalar un paquete o no, puede mirarse la descripción completa del mismo a través de:

$ apt show pv

Es también muy útil saber cuál es la lista de paquetes disponibles:

$ apt list

que sin ningún argumento das devolverá todos los paquetes existentes, instalados o no. Podemos afinar esta lista utiliziando patrones[8], como por ejemplo:

$ apt list 'p[av]*'

que mostrará todos los paquetes cuyo nombre empieze por «pa» o «pv». Además se puede añadir las opciones --installed (sólo paquetes instalados) o --upgradable (sólo paquetes con versión más reciente en los repositorios). Por ejemplo:

$ apt list --installed 'n*'

devuelve todos los paquetes instalados cuyo nombre empieza por «n».

2.7.1.1.5. La familia apt-

Es, sin duda, preferible apt ya que reducen a una sola orden las operaciones básicas de gestión de software y, además, ofrece un aspecto mejorado (colores, barra de progresión, etc.). No obstante, resumimos aquí las equivalencia entre la orden apt y las órdenes de esta familia:

Orden apt

Familia apt-*

apt install

apt-get install

apt remove

apt-get remove

apt purge

apt-get purge

apt update

apt-get update

apt upgrade

apt-get upgrade

apt full-upgrade

apt-get dist-upgrade

apt autoremove

apt-get autoremove

apt search

apt-cache search

apt show

apt-cache show

apt list

dpkg -l

Es, no obstante, muy importante hacer una precisión. Las acciones que implican descargar paquetes del repositorio (install, upgrade) no borran estos paquetes descargados al completarse con éxito, a diferencia de apt, sino que estos archivos .deb se van acomulando en el directorio /var/cache/apt. Por ello, tras la acción, es preciso borrar la caché con:

# apt-get clean.

2.7.1.1.6. Otras operaciones

Bajo este epígrafe se enumerarán algunas otras operaciones relacionadas con los paquetes y la gestión de paquetes, pero que se realizan con menor frecuencia.

2.7.1.1.6.1. Acciones sobre paquetes

Es muy útil conocer cuáles son los archivos que contiene un paquete:

$ dpkg -L <paquete>

o a qué paquete pertenece un determinado archivo. Por ejemplo, si quisiéramos saber qué paquete instala el comando cp:

$ dpkg -S $(which -a python3)

Nota

Obsérvese que se ha preferido incluir la ruta completa (/usr/bin/python3, que es la salida de which python3) frente al nombre solo (python3). Esto es debido a que la búsqueda funciona de tal forma que devuelve cualquier paquete que contenga un archivo en cuya ruta aparezca la palabra python3 y hay muchos archivos en el sistema que cumplen esto. Por tanto, si hubiéramos hecho dkpg -S python3 se habrían devuelto infinidad de resultados. Hágase la prueba.

Advertencia

A partir de Buster, no existe el directorio /bin, sino que éste es un enlace simbólico a /usr/bin. Esto es un problema, cuando buscamos el paquete al que pertenece un ejecutable instalado en /bin, puesto que en la variable PATH /usr/bin aparece antes y en consecuencia, será esta ruta la que nos devuelva which. Como en el contenido de los paquetes (que es donde busca dpkg) aparece la ruta /bin/, se nos dirá equivocadamente que no hay ningún paquete que contenga el ejecutable:

$ which ls
/usr/bin/ls
$ dpkg -S $(which ls)
dpkg-query: no se ha encontrado ningún paquete que corresponda con el patrón /usr/bin/ls.

Por ese motivo, se ha añadido la opción -a que devuelve todos los ejecutables que se encuentran con tal nombre y no solamente el primero:

$ which -a ls
/usr/bin/ls
/bin/ls
$ dpkg -S $(which -a ls)
dpkg-query: no se ha encontrado ningún paquete que corresponda con el patrón /usr/bin/ls.
coreutils: /bin/ls
y, en consecuencia, which devolverá como ruta

esta segunda localización. Hagáse la prueba con cp o ls y comprobará que la orden no devuelve el paquete que los contiene (coreutiils) ya que dentro de este paquete la ruta de ambos programas es /bin/ (/bin/cp, /bin/ls) mientras que la consulta con which devolverá /usr/bin/cp y /usr/bin/ls, respectivamente.

dpkg puede también ser útil cuando instalamos a mano un paquete .deb descargado, por ejemplo, de una web que lo proporciona en este formato:

# dpkg -i paquete.deb

Cuando se obra así, muy comúnmente, tal paquete necesita de otros que no están aún instalados en el sistema. Como de resolver dependencias se encarga apt, pero no dpkg, el paquete quedará a medio instalar e inusable. Para resolverlo y que automáticamente se instalen las dependencias basta con hacer:

# apt -f install

Nota

En cualquier caso, es preferible la orden:

# apt install ./paquete.deb

que se encargará no sólo de instalar el paquete, sino de satisfacer sus dependencias.

2.7.1.1.6.2. Acciones sobre el sistema de paquetes

En ocasiones es conveniente saber cuáles son las dependencias de un paquete:

$ apt depends pv
pv
  Depende: libc6
  Sugiere: doc-base

Y en otras qué paquetes dependen de él:

$ apt rdepends pv
pv
Reverse Depends:
  Depende: bfh-container-server
  Depende: xvidenc
  Recomienda: h264enc
  Depende: divxenc
  Depende: sanoid
  Depende: progress-linux-container-server
  Recomienda: open-infrastructure-compute-tools
  Recomienda: mariadb-server
  Depende: hashcheck
  Sugiere: charliecloud-builders

En este último caso, se devolverán todos los paquetes que requieran instalar aquel por el que se pregunta, estén o no instalados en el sistema. Lo habitual es que, cuando hagamos la pregunta, nos interese conocer sólo los paquetes realmente instalados, porque nuestra intención es conocer qué paquete es el responsable de que tengamos algo instalado. Por ejemplo:

$ apt list policykit-1
Listando... Hecho
policykit-1/testing,now 122-3 amd64 [instalado, automático]

En mi sistema de escritorio se encuentra instalado el paquete policykit-1 que no instalé explícitamente, puesto que aparece como automático. Como nunca pedí instalar sugerencias al utilizar apt, no necesito la información sobre sugerencias (ni reemplazos, etc. que tampoco me aportan mucho), sino estrictamente las dependencias y recomendaciones. En este caso, averiguar qué paquete provocó la instalación de éste se logra así:

$ apt rdepends --installed --no-suggests --no-breaks --no-replaces policykit-1
policykit-1
Reverse Depends:
  Depende: rtkit

Ya lo tenemos: es rtkit, pero:

$ apt list rtkit
Listando... Hecho
rtkit/testing,now 0.13-5 amd64 [instalado, automático]

éste paquete también se instaló automáticamente. Podríamos repetir la operación indagando sobre él, pero en vez de eso podemos añadir la opción --recurse que hará todo el trabajo por nosotros:

$ apt rdepends --installed --no-suggests --no-breaks --no-replaces --recurse policykit-1
policykit-1
Reverse Depends:
  Depende: rtkit
rtkit
Reverse Depends:
  Recomienda: pulseaudio
pulseaudio
Reverse Depends:
  Recomienda: pavucontrol
pavucontrol
Reverse Depends:

rtkit se instaló porque fue una recomendación de pulseaudio y éste quizás porque es a su vez una recomendación de pavucontrol:

$ apt list pulseaudio pavucontrol
Listando... Hecho
pavucontrol/testing,now 5.0-2 amd64 [instalado]
pulseaudio/testing,now 16.1+dfsg1-2+b1 amd64 [instalado]

En realidad, no fue así, sino que ambos se instalaron a mano (aunque podría haber ocurrido que el único instalado explicitamente fuera pavucontrol[9]). Por tanto, mientras pavucontrol (y pulseaudio) se encuentre en el sistema, policykit-1 no podrá desinstalarse[10].

Nota

Existen también apt-cache depends y apt-cache rdepends.

Hay un aspecto de los paquetes interesante también que aún no se ha mencionado: las marcas, que operan en dos aspectos distintos:

  • Un paquete puede estar marcado como de instalación manual o automática. Lo primero quiere decir que el paquete fue explícitamente instalado, mientras que lo segundo que se instaló para resolver una dependencia. Tiene importancia, porque en el segundo caso, si se eliminan los paquetes dependientes de él, alguno de los cuales provocó su instalación, el sistema nos sugerirá que lo desinstantemos (con apt autoremove). Estas marcas las establece el gestor de paquetes sin nuestra intervención, pero nosotros podemos forzar que el paquete la cambie.

  • Un paquete puede estar marcado como retenido (hold). Si es así, no se actualizará ni se eliminará jamás, a menos que revoquemos la marca (unhold).

Para manejar las marcas, disponemos del comando apt-mark:

  1. Marca como automáticamente el paquete pv:

    # apt-mark auto pv

  2. Marca como instalado manualmente el paquete pv:

    # apt-mark manual pv

  3. Muestra todos los paquetes instalados manualmente:

    $ apt-mark showmanual

  4. Muestra todos los paquetes instalados automáticamente:

    $ apt-mark showauto

  5. Marca el paquete pv como retenido:

    # apt-mark hold pv

  6. Desmarca el paquete pv como retenido:

    # apt-mark unhold pv

  7. Muestra los paquetes retenidos:

    # apt-mark showhold

Además, con apt-mark podemos saber los paquetes instalados (showinstall), eliminados (showremove) y purgados (showpurge).

2.7.1.1.6.3. Adición de repositorios extraoficiales

En ocasión nos encontramos con la necesidad de añadir repositorios extraoficiales que empaquetan alguna utilidad interesante. Por ejemplo, este que permite instalar un paquete para Google Earth:

# cat >> /etc/apt/sources.list.d/google.list
deb http://dl.google.com/linux/earth/deb/ stable main

El problema de ello es que los repositorios está firmados con certificados PGP y al intentar actualizar las listas de paquetes es bastante probable que nuestro apt no disponga de la clave pública y no tenga confianza. En consecuencia, se malogrará la descarga de la lista de paquetes disponibles en el repositorio y nos quedaremos sin poder instalar los paquetes que proporciona:

# apt update
[...]
W: Error de GPG: http://dl.google.com/linux/earth/deb stable Release: Las firmas siguientes
no se pudieron verificar porque su clave pública no está disponible: NO_PUBKEY 1397BC53640DB551
E: El repositorio «http://dl.google.com/linux/earth/deb stable Release» no está firmado.
N: No se puede actualizar de un repositorio como este de forma segura y por tanto
está deshabilitado por omisión.
[...]

Para solucionarlo basta con importar la clave pública requerida a nuestro anillo personal de claves y, hecho esto, exportarla al anillo de apt. Use el identificador que proporciona el propio apt (en el ejemplo, 1397BC53640DB551):

# gpg --keyserver keys.gnupg.net --recv-key 1397BC53640DB551
# gpg -a --export 1397BC53640DB551 | apt-key add -

Ver también

Consulte cómo funciona el cifrado PGP.

2.7.1.1.6.4. Actualizaciones automáticas

Es posible automatizar la actualización de paquetes de modo que no se requiera intervención humana. Esto tiene una gran ventaja y un gran inconveniente:

  • La ventaja es que tendremos siempre actualizado el sistema sin tener que preocuparnos.

  • La desventaja es que no controlamos cuándo se actualizan los paquetes y la actualización a una nueva versión puede introducir incompatibilidades con la configuración que hayamos hecho. Por eso motivo, no es nada recomendable activar esta posibilidad si corremos una rama distinta de la estable.

La automatización se logra gracias al paquete unattended-upgrades, para el que tenemos unas instrucciones en la wiki de Debian <https://wiki.debian.org/UnattendedUpgrades>.

2.7.1.1.6.5. Mezclando ramas y arquitecturas

Lo habitual es que nuestro sistema esté constituido por paquetes de una sola arquitectura (muy pòsiblemente, amd64) y una única rama (stable, testing, etc.). En ocasiones, sin embargo, necesitamos mezclar, lo cual es posible, pero exige ser bastante cuidadoso.

2.7.1.1.6.5.1. Mezcla de arquitecturas

Lo normal es disponer de un sistema con paquetes compilados para amd64, pero puede darse el caso de que necesitemos instalar un paquete que no es software libre y sólo está compilado para 32 bits (i386). Dado que son arquitecturas compatibles (un ejecutable de 32 bits se puede ejecutar en una plataforma de 64 bits), no hay ningún problema con el programa; el problema real es que este programa necesitara muy probablemente librerías de 32 bits que se encuentran en otros paquetes; y, aunuqe dispongamos de las correspondientes de 64 bits, no servirá.

Para conocer la arquitectura principal de nuestro sistema podemos ejecutar lo siguiente:

$ dpkg --print-architecture
amd64

Así que si quisiéramos añadir la arquitectura i386:

# dpkg --add-architecture I386

Para que el cambio tenga efecto, es necesario refrescar la lista de paquetes:

# apt-get update

De lo cual resulta:

$ dpkg --print-architecture
amd64
$ dpkg --print-foreign-architectures
i386

Es decir, tenemos un sistema cuya arquitectura principal es amd64, y que tiene como arquitectura adicional i386. Esto significa que cuando pidamos instalar o eliminar un paquete, se presupondrá que nos referimos a la arquitectura amd64 y que sólo en caso de que especifiquemos instalaremos (o eliminaremos) un paquete para arquitectura i386:

# apt-get install pv:i386

Si en algún momento quiere eliminarse la arquitectura adicional, se deben borrar todos los paquetes para tal arquitectura, antes de eliminarla:

# apt-get purge '.*:i386'
# dpkg --remove-architecture I386
2.7.1.1.6.5.2. Mezcla de ramas

Otra posibilidad de mezcla es la de mezclar distintas ramas. Debe haber una verdadera razón para ello y no dejarse a la ligera, porque puede traer problemas.

Antes de embarcarse en ello, es necesario conocer precisamente cuál es el criterio que sigue Debian para instalar unos paquetes frente a otros:

$ man apt_preferences

Aquí expondremos de ello un pequeño resumen y algunas reglas útiles.

En principio, si en nuestro /etc/apt/sources.list sólo incluímos repositorios de una rama (que es lo habitual), obviamente, sólo se instalarán repositorios de tal rama, puesto que los únicos paquetes de los que tendrá conocimiento nuestro sistema serán sus paquetes. Ahora bien, ¿qué ocurre si nuestro sources.list es el siguiente?:

 1### Distribución estable
 2deb http://ftp.cica.es/debian/ jessie main
 3
 4# Acutalizaciones y seguridad
 5deb http://ftp.cica.es/debian/ jessie-updates main
 6deb http://security.debian.org/ jessie/updates main
 7
 8### Backports
 9deb http://httpredir.debian.org/debian jessie-backports main
10
11### Distribución en pruebas
12# deb http://ftp.cica.es/debian/ stretch main

Como vemos, tenemos en el sistema la rama estable junto a sus actualizaciones, los backports y, además, la distribución de pruebas. Un batiburrillo, que hay que saber gestionar.

Para pronosticar qué ocurre, es necesario saber primero que todos los paquetes llevan asociada una prioridad, que se calcula según las siguientes reglas:

Prioridades predefinidas

Prioridad

Paquetes

1

Ramas[11] con la opción NotAutomatic: yes[12], pero sin la opción ButAutomaticUpgrades: yes.

100

Paquetes instalados.

Ramas[13] con las opciones NotAutomatic: yes y ButAutomaticUpgrades: yes.

500

Ramas que no sean las anteriores ni la rama objetivo. Lo habitual es la rama objetivo no esté definida.

990

Rama objetivo.

Y las reglas para decidir si un paquete se instala o no son estas:

  1. Se instala el paquete con mayor prioridad, aunque para que se instale un paquete de una versión más reciente a la instalada, se exige además que tenga una prioridad de al menos 1000.

  2. Si coinciden las prioridades, se instala el paquete más reciente.

Sabido esto, podemos volver a la nuestro sources.list de ejemplo. Resulta que en él todas las ramas tienen prioridad 500, excepto la de backports que tiene prioridad 100. Consecuentemente, cada vez que intentemos instalar un paquete, se evitará la rama backports y se instalará aquel más reciente, que se encontrarán normalmente en las ramas de actualización y seguridad.

¿Cómo podemos entonces instalar un paquete de backports? Muy sencillo: basta con hacer tal rama, la rama objetivo para esa instalación. Eso se hace añadiendo la opción -t a la orden:

# apt-get install -t jessie-backports nginx

Advertencia

Este comando no implica sólo instalar el paquete nginx de backports, sino él y todas sus dependencias. Si entre sus dependencias hay librerías, incluso las más básicas, entonces se instalarán (o actualizarán) también. Por lo general, backports está pensada para que haya versiones más recientes de software, pero que estas versiones se hayan compilado con las mismas librerías básicas que usa la estable. Por tanto, al realizar esta operación, sólo actualizaremos los paquetes más intimamente ligados con la aplicación que queremos actualizar. Pero esto no es aplicable a la rama testing ni a la inestable.

El archivo, tal y como está, guarda bastante equilibrio: instalaremos paquetes de la estable, convenientemente actualizada con paquetes de seguridad, y sólo si explícitamente pedimos la actualización de un paquete que haya en backports se llevará a cabo. Ahora bien, ¿qué ocurre si descomentamos la línea referente a la rama en pruebas? Que el equilibrió se romperá: los paquetes de la rama en pruebas también tienen prioridad 500, pero en su mayoría serán versiones más recientes y que, además, están en constante actualización. La consecuencia será que si actualizamos todo el sistema, pasaremos de tener la rama estable a tener la rama en pruebas y que todos los paquetes que instalemos serán de esta última versión. Es decir, que el resto de líneas de sources.list sobrarán por completo.

Para tener mayor control, apt permite alterar las prioridades predefinidas. Esto se hace modificando (o creando el archivo /etc/apt/preferences[14]), dentro del cual se incluyen estructuras del siguiente tipo separadas por una línea en blanco:

Package: <expr_paquete>
Pin: <selector>
Pin-Priority: <N>

es decir, en cada estructura definimos una expresión que escoge los paquetes para los que se hace la definición, un selector que indica para qué ejemplares del paquete (versión, rama a la que pertenece, etc.) y, por último, la prioridad que le pensamos otorgar.

Línea Package

Para expresar el paquete hay varias posibilidades. Las dos más simples son indicar el nombre exacto del paquete o escribir un *, que (como es lo habitual) significa cualquier paquete. Las otras dos son:

  • Espresiones glob, esto es, las expresiones que se usan en bash. Por ejemplo, python3-* haría referencia a todos los paquetes que comienza por python3-.

  • Expresiones regulares que deben delimitarse entre barras. POr ejemplo, /py/ refiere todos los paquetes que contengan la subcadena py.

Línea Pin

La selección del ejemplar del paquete la determina el contenido del campo Pin. Hay diferentes criterios para realizar esta selección:

  • La versión del propio paquete:

    Pin: version 1.10*

    En este caso, no se especifica una versión concreta exacta, sino cualquier version que empiece por 1.10.

  • El origen del paquete, esto es, de dónde se descarga:

    Pin: origin "ftp.cica.es"

    Si se usa una cadena vacía (origin ""), el paquete se descarga de un sitio local.

  • Las propiedades de la distribución a la que pertenece el paquete. Son diversas y se pueden consultar el los archivos *Release, citados en una de las notas al pie. Se enumeran aquí algunas propiedades, expresando el nombre del campo con que se enuncian en tal archivo:

    • La rama con su nombre genérico stable, testing, etc. (Suite):

      Pin: release a=testing

    • La rama con su nombre clave (Codename):

      Pin: release n=stretch

    • La versión de la distribución (Version):

      Pin: release v=8

      Nótese que sólo las versiones estables tienen asignada una versión, por lo que sólo podremos referir la versión estable en curso o anteriores.

    • El componente:

      Pin: release c=main

    • La distribución (Debian, ubuntu) relacionada con dos etiquetas Label:

      Pin: release l=Ubuntu

      y Origin:

      Pin: release o=Ubuntu
Línea Pin-Priority:

Símplemente hay que indicar la prioridad numérica. Para fijar una adecuada, conviene tener en cuenta que, de acuerdo con las prioridades predeterminadas, el comportamiento de un paquete ante la instalación o la actualización será el siguiente (P es su prioridad):

P>=1000:

El paquete se instala en cualquier caso, incluso aunque haya una versión instalada más reciente.

990<=P<1000:

El paquete se instala por encima incluso de los provenientes de la rama objetivo. No lo hará unicamente si hay una versión más reciente instalada.

500<=P<990:

El paquete se instala a menos que la versión instalada sea más reciente o haya un ejemplar disponible en la rama objetivo.

100<=P<500:

Sólo se instala el paquete si no hay otro ejemplar disponible en alguna rama y es más reciente que el instalado.

0<P<100:

Sólo se instala si no hay ninguna versión disponible ni instalada.

P<0:

El paquete no se instalará jamás.

Teniendo en cuenta todo esto, una posibilidad para conciliar tener a la vez como fuente testing y stable sería esta:

Package: *
Pin: release a=testing
Pin-Priority: 99

De este modo, al hacer:

# apt-get install paquete

Sólo se instalaría un paquete de la rama en pruebas si no estuviera disponible en la rama estable. Eso sí, si necesitara versiones de librerías posteriores a las que se encuentran en la estable, no se llegaría a instalar, porque no se podría satisfacer sus dependencias. Si en este caso hiciéramos:

# apt-get install -t testing paquete

Esto sí se instalaría a costa de instalar también versiones en pruebas de ciertas librerías. Esto, sin embargo, no es recomendable, porque pueda dar pie a problemas. En este caso, sería más recomendable descargar el paquete fuente de testing e intentar compilarlo con las librerías de la estable.

Por último, cuando se mezclan distintas ramas es conveniente saber para un paquete qué versión proporciona cada una de ellas. Para ello es muy útil el comando apt-show-versions disponible en el paquete del mismo nombre (no viene instalado por defecto):

$ apt-show-versions -a -p pv
pv:amd64 1.5.7-2 install ok installed
pv:amd64 1.5.7-2 stable  ftp.cica.es
No stable-updates version
pv:amd64 1.6.0-1 testing ftp.cica.es
pv:amd64/stable 1.5.7-2 uptodate

Se ha ejecutado la orden en un sistema que se provee de la estable y testing y con las preferencias ajustadas tal y como se ha indicado (los paquetes de testing tiene prioridad 99). En estas condiciones la orden nos informa de que tenemos intalada la versión 1.5.7, que es justamente, la de la versión estable; que hay otra versión más moderna (1.6.0) en testing, pero que estamos actualizados (uptodate). Y lo estamos justamente por el hecho de haber definido la prioridad.

2.7.1.1.7. Compilación de paquetes

Aunque no es algo habitual y además resulta engorroso de mantener[15], es bastante sencillo compilar una código fuente para obtener los paquetes compilados. Lo primero es añadir a /etc/apt/sources.list la línea que nos permite acceder a los paquetes de las fuentes. Por ejemplo:

deb-src http://ftp.cica.es/Debian/ stretch main

Y, hecho esto, se deberá actualizar la lista de paquetes:

# apt update

y añadir las herramientas para compilar:

# apt install build-essential

Con todo esto la compilación es muy sencilla. Requiere descargar los paquetes que exige la compìlación del que pretendemos compilar[16] (supongamos que pv):

# apt-get build-dep pv

y descargar el paquete con el código fuente:

# cd /usr/src
# apt-get source pv

E ir al directorio donde se almacena y compilar:

# cd pv-1.6.0
# dpkg-buildpackage -us -uc

Si la compilación acaba sin problemas, el paquete .deb estará en el directorio superior y bastará con instalarlo:

# cd ..
# dpkg -i pv_1.6.0-1_amd64.deb

Nota

Puede ocurrir que la compilación del paquete genere varios paquetes compilados.

Nota

El directorio /usr/src quedará lleno de archivos relacionados con la compilación y el código fuente que pueden borrarse cuando acaba el proceso.

No relacionado con la compilación, pero sí con la obtención de un paquete .deb es el caso en que queremos reconstruir el paquete a partir de los archivos que tenemos instalados en el disco duro, bien porque no encontramos cómo hacernos con el .deb original, bien porque hemos cambiado sus archivos de configuración y queremos empaquetarlo en el estado en el que está en nuestro sistema para trasladarlo a otro. En ese caso es muy útil la orden dpkg-repack que hay que instalar primero:

# apt install dpkg-repack
# dpkg-repack pv

2.7.1.1.8. Destripando paquetes

Los archivos .deb son empaquetados comprimidos de archivos que, además de poder instalarse, pudeden descomprimirse y desempaquetarse a fin de poder acceder a su interior. Para lograr esto, es conveniente instalar

fakeroot

Simula que el usuario es el administrador dentro de un entorno en el que se manipulan archivos.

Para acceder al contenido de un .deb, lo primero es conseguir uno. Consigámoslo, descargando el archivo con apt-get, pero sin llegar a instalarlo:

# apt install -d pv

La orden habrá almacenado el archivo descargado en /var/cache/apt/archives. Podemos analizar el contenido de este archivo haciendo uso del comando:ar:

$ ar t /var/cache/apt/archives/pv_*.deb
Debian-binary
control.tar.gz
data.tar.xz

Contiene tres archivos, el primero guarda simplemente la versión del formato .deb y los otros dos son archivos empaquetados y comprimidos, uno (data.tar.xz) guarda los archivos en sí que constituyen el paquete y el otro (control.tar.gz) los archivos de metainformación, es decir, los archivos que sirven para identificar cuál es el paquete, qué archivos debe contener o qué acciones hay que realizar cuando se instala o se elimina el paquete del sistema. No entraremos a describir cuáles son estos archivos control, pero puede leerse información al respecto aquí).

No obstante, no segujiremos por este camino, puesto que el propio dpkg tiene las herramientas necesarias para desempaquetar el archivo:

$ cd /tmp
$ mkdir CACA
$ dpkg -x /var/cache/apt/archives/pv_*.deb CACA
$ dpkg -e /var/cache/apt/archives/pv_*.deb CACA/DEBIAN

Usamos como directorio para almacenar el contenido /tmp/CACA. La primera operación descomprime los archivos en sí dentro de tal directorio, de manera que estos forman la misma estructura que tienen cuando se instalan en el sistema, mientras que la segunda almacena dentro de un subdirectorio llamado DEBIAN los archivos de metainformación. En este punto podríamos realizar modificaciones de tanto de los archivos de datos como de los de control (¡ojo! que el archivo de control md5sums almacena las comprobaciones de la integridad de los archivos).

Si en algún momnento quisiéramos reconstruir el archivo, podríamos hacer lo siguiente:

$ cd /tmp/CACA
$ dpkg-deb -b . ../pv_1.5.7-2_amd64.deb

Nota

En realidad, conociendo cuáles son los archivos de control y cómo se escriben, es posible crear nuestros propios archivos .deb. Basta con reproducir la estructura que hemos visto al descomprimir el archivo y empaquetar todo con dpkg-deb.

2.7.1.1.9. Ejercicios sobre gestión de software

  1. Actualizar el sistema:

    1. Actualice la lista de paquetes.

    2. Actualice en sí el sistema sin más.

    3. Como alternativa a lo anterior, actualice a la vez que elimina paquetes no necesarios.

  2. Hacer una actualización completa del sistema, de modo que se actualice software aunque el proceso suponga sustituir un paquete por varios distintos.

  3. Instalar las herramientas para soportar NTFS.

  4. Instalar la versión ligera del servidor web nginx.

  5. En la misma orden desinstalar la versión anterior e instalar la versión completa.

  6. Averiguar a qué paquete pertenece el ejecutable nginx.

  7. Comprobar si tenemos instalado, el paquete gcc.

  8. Consultar para qué sirve el paquete vlan.

  9. Buscar algún paquete que nos permita jugar al Pacman (pero para consola de texto, porque no tenemos entorno gráfico)

  10. Desinstalar el juego anterior.

2.7.1.2. Paquetería universal (Flatpak)

Los paquetes de Flatpak sólo deben usarse si dentro de los paqutes de la distribución no hay solución posible para el software que necesitamos. En ese caso, echar mano de estos paquetes universales es una buena solución, pero habrá primero que preparar el sistema instalado:

# apt install flatpak

y añadiendo el repositorio oficial de paquetes:

# flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Hecho esto, ya estaremos en disposición de instalar paquetes directamente del repositorio que hemos denominado «flathub» (el repositorio oficial por otra parte). Ahora podemos buscar software de todos los repositorios que tengamos definidos:

# flatpak search firefox

e instalarlo:

# flatpak install flathub org.mozilla.firefox

Es probable que la instalación de esta aplicación sea enormemente pesada, ya que, si es la primera de Flatpak que instalamos, no habrá ninguna dependencia satisfecha; y será necesario descargarlas todas.

Para ejecutar la aplicación deberemos usar también Flatpak:

$ flatpak run org.mozilla.firefox

Las aplicaciones puede ser facilmente listadas con:

$ flatpak list --app

actualizadas:

$ flatpak update

o borradas:

$ flatpak uninstall org.mozilla.firefox

Nota

Esta paquetería permite la instalación de paquetes exclusivamente para un usuario añadiendo la opción --user.

Ver también

Para más información, consulte Usando Flatpak

Notas al pie