makepkg es la herramienta más primitiva que puedes usar para compilar paquetes que vengan de AUR en Arch Linux y distribuciones relacionadas (Manjaro, EndeavourOS, Xero Linux…). La mayoría de personas inmediatamente van a querer dar el salto a un gestor de paquetes compatible con AUR, como Yay o Paru, por las limitaciones que tiene vivir únicamente de makepkg exclusivamente.
Sin embargo, en algunos casos puede salvar la vida cuando todo lo demás falla, así que creo que es muy relevante saber, al menos cómo descargar y compilar un paquete de AUR con makepkg. ¿Por qué? Así como mínimo, porque para instalar Yay necesitarás usar algo, ¿no? ¿o pretendes mantener yay fuera de la base de datos de pacman? Además, si eres una de esas personas que saben cómo crear y modificar PKGBUILDs, trabajar con makepkg te será más sencillo en muchos casos.
Como ya he mencionado en el pasado, las distribuciones GNU/Linux están conectadas a un repositorio de paquetes, que es un bazar donde puedes encontrar todo tipo de programas para tu ordenador, que instalas con un comando a través de tu gestor de paquetes en la terminal, o mediante una herramienta gráfica como KDE Discover o GNOME Software.
Sin embargo, una de las características típicas de los repositorios de las distribuciones GNU/Linux es que el software que encuentras ahí tiene cierto grado de oficialidad. Los paquetes han sido probados para asegurarse de que funcionen en la versión de GNU/Linux que estés utilizando, y además se proporcionan pre-compilados para que sea tan rápido como descargar el paquete y extraer.
Como alternativa, AUR es el Arch User Repository. Es otro repositorio, pero en este caso contiene paquetes preparados por la comunidad. Cualquier persona puede contribuir con su propio paquete, y lo normal es que esos paquetes están mantenidos por personas que no formen parte de Arch, sino que sean también participantes de la comunidad. En algunos casos puede ser la misma persona que fabrica el programa, y típicamente será alguien que, en cualquier modo, al menos lo utilice.
¿Qué diferencia hay?
Los paquetes que encuentras en AUR se diferencian de los que te vas a encontrar en el repositorio central de tu distribución por al menos las siguientes diferencias.
La principal diferencia es que en el caso de AUR, lo que te descargas es la receta, también conocida como PKGBUILD. Este es el script que se usa para fabricar un paquete desde el código fuente. El proceso es casi automático, porque puede descargar las dependencias necesarias para fabricar el paquete, y como resultado obtienes un archivo de tipo .pkg.tar.zst, que puedes instalar con Pacman. En otras palabras: mientras que del repositorio principal de Arch te descargas un paquete pre-compilado en los propios servidores de Arch, y por lo tanto, más rápido de instalar, con AUR el paquete lo compilas tú en tu máquina, usando tiempo y recursos.
Otra es que no tiene por qué estar probado que funcione. En otras palabras: un paquete que instalas con pacman desde los repositorios centrales de Arch debería instalar y ejecutar bien, porque alguien ha probado que funcione. Sin embargo, los repositorios AUR se basan en la vigilancia continua de la comunidad. Lo normal es que un paquete se instale bien, pero a veces el programa puede cambiar y las instrucciones para fabricar el paquete pueden quedar obsoletas. Por suerte, modificar un PKGBUILD tampoco es muy dificil, así que si tienes experiencia manteniendo shell scripts, es incluso posible que puedas corregirlo con tu editor de textos tras leer las instrucciones actualizadas, y así poderlo instalar.
Y la otra más importante, es que no son paquetes verificados. Esto es importante en temas de seguridad. Cuando instalas un paquete desde el repositorio central de Arch Linux, no sólamente está pre-compilado en los servidores de Arch. Al prepararse en un entorno especial y restringido, y al llevar firmas, es más dificil que se cuele malware en un paquete (no imposible, como aprendimos durante el drama de XZ, aunque por suerte en el caso de Arch Linux era imposible ejecutar la parte de código comprometida). Sin embargo, en el caso de AUR, las recetas las usas bajo tu propia responsabilidad.
Con esto no quiero decir que usar AUR sea malo. Al contrario, AUR es parte de lo que hace que la experiencia de usar una distribución basada en Arch sea tan buena. Hay una comunidad activa que se ocupa de proporcionar instrucciones de integración de casi cualquier paquete que se te ocurra, para que puedas instalarlo en tu sistema usando el gestor de paquetes, con las ventajas que eso aporta, en vez de tener que hacerlo a mano usando métodos que no permiten al sistema luego administrar los archivos del programa.
¿Es seguro usar AUR?
AUR es a menudo seguro de usar. Por lo general, si instalas un paquete popular desde AUR, incluso si no sabes verificar estas cosas, puedes asumir que colectivamente la comunidad está bastante pendiente de estos temas, y que hay suficientes ojos mirando que no pase nada raro.
Sin embargo, como digo, esto pasa con los paquetes populares. Existen muchos paquetes que no tienen votos, ni popularidad, y en algunos casos, ni siquiera maintainer. El maintainer es la persona que está a cargo de un paquete de AUR. Cualquier persona puede volverse maintainer, y aunque lo normal es que lo mantenga una persona que lo usa activamente (y que por eso tiene interés en que la receta funcione bien), podría ocurrir que un paquete quede huérfano (es decir, sin maintainer) y alguien se aproveche de la situación para adoptarlo y modificarlo de forma maliciosa. Esto pasó en 2018 con un paquete que instalaba Acrobat Reader para Linux y un par de paquetes más. La persona involucrada en la publicación del malware fue expulsada del sistema AUR, pero pegó un buen susto.
Lamentablemente, la interfaz web de AUR tampoco te dice si un paquete ha cambiado de maintainer hace poco, aunque en mi opinión, debería. Sí es verdad que a veces los comentarios de un paquete en la página web pueden contener información interesante. No está de más revisar antes de instalar nada y confirmar que no hay nadie dando la voz de alarma.
En cualquier caso, dado que AUR no aporta ningún tipo de garantías, dejándote a ti como responsable de lo que sea que instales, cuando te animes a usar AUR, hay un par de consejos que deberías tener en cuenta.
Uno es que, aunque tengas un buen frontend para instalar paquetes desde AUR (yo uso yay en este momento, por ejemplo), deberías aprender a usar el comando makepkg, por lo que pueda pasar. Todas las instalaciones de Arch Linux traen makepkg, que es el programa que sirve para convertir una receta en formato PKGBUILD a paquete compilado que puedes instalar con Pacman.
Otro es que leas la receta que estás a punto de ejecutar. En otras palabras, que revises el contenido del archivo PKGBUILD antes de fabricar la receta. Lo normal es que tu frontend te pregunte si quieres hacer esto. Por ejemplo, yay lo hace. No deberías saltarte este paso, y deberías inspeccionar como mínimo que no se descarguen archivos sospechosos desde otras fuentes que no sean la de la página del programa oficial. Cuantos más conocimientos tengas de shell scripting, mejor. Si sabes cómo fabricar scripts, deberías leerte el script completo y vigilar que entre los pasos de compilación del paquete o de instalación no haya algo sospechoso.
VanillaOS tiene papeletas a volver a hacer interesante y divertido el ecosistema GNU/Linux durante 2023, y en este artículo te voy a contar las razones por las que puede ocurrir esto.
Se espera que en un par de semanas salga la primera beta pública de VanillaOS, una nueva distribución basada en Ubuntu Linux. Esta distribución tiene papeletas a volver a hacer interesante y divertido el ecosistema GNU/Linux durante 2023, y en este artículo te voy a contar las razones por las que puede ocurrir esto.
VanillaOS está basada en Ubuntu Linux, pero no es simplemente otro Ubuntu cambiado de piel, sino que introduce cambios sensibles a la forma en la que trabaja la distribución, que pueden hacer del día a día una experiencia interesante. Van bastantes años donde las distribuciones parece que se han estancado y que avanzan lentamente. Todas las distros están basadas en otra ya existente cambiando algunas cosas, y apenas se introducen cambios interesantes que valgan la pena de cara a evolucionar el estado del arte.
VanillaOS rompe los moldes e introduce una serie de cambios a la forma en la que funciona el sistema operativo que, si bien no son para todo el mundo (mucho menos tal vez para personas que llegan a GNU/Linux por primera vez), pueden servir de inspiración para funciones interesantes que tal vez en unos años veamos incorporadas en otras distribuciones.
Una experiencia GNOME mainstream
El primero de estos aspectos es el entorno de escritorio. GNOME. En principio no debería suponer ninguna novedad, puesto que hoy en día Ubuntu también utiliza GNOME. Sin embargo, VanillaOS trae un GNOME puro y sin añadidos de Canonical. Este es un factor determinante. Ubuntu trae una versión de GNOME altamente modificada, con un dock preinstalado, con soporte para mostar iconos en el escritorio, y con un aspecto de pantalla altamente modificado.
Render de VanillaOS propuesto por sus autores. Foto tomada del sitio web oficial.
Si queda en la sala algún fan del viejo Ubuntu GNOME, posiblemente sepa a qué me refiero con esto. Cuando Ubuntu se pasó a GNOME en 2017 y abandonó Unity, esto deprecó inmediatamente Ubuntu GNOME, otra distribución spin que previamente había aparecido para ver cómo sería Ubuntu si utilizase el por entonces reciente GNOME 3. Sin embargo, el salto de Ubuntu GNOME 16.04 a Ubuntu 18.04, pese a que sea el mismo entorno de escritorio, claramente dejó un poco que desear a quienes buscasen una experiencia más neutra. Ubuntu GNOME era un GNOME puro, ligero y azul. En cambio, Ubuntu 18.04 era naranja y con paneles cambiados. En ese sentido, VanillaOS recuerda bastante a lo que era el viejo Ubuntu GNOME. Una interfaz de usuario minimalista y sin muchos cambios respecto a la línea base de GNOME.
Capacidad de elección
Uno de los aspecto más característicos de Ubuntu es su preferencia hacia el sistema Snap. Este año ya vimos como Ubuntu delegaba en Snap ciertos paquetes del sistema esenciales, tales como Firefox, el cual ahora mismo se actualiza siempre por Snap. Otras distribuciones basadas en Ubuntu, como Linux Mint, se bajaron del barco y ofrecen derivados en los que el soporte para Snap está eliminado.
En vez de imponer Snap, una de las primeras cosas que hace el sistema operativo tras instalarse es preguntar qué tipo de gestor de aplicaciones se va a querer utilizar: Snap, Flatpak, AppImage, o una mezcla de las tres opciones. Lo que significa que es más fácil de eliminar el soporte para Snap si no tienes previsto utilizarlo, y mantenerte usando exclusivamente Flatpak si ese es tu interés.
El asistente de configuración de VanillaOS preguntando por el tipo de gestor de paquetes a utilizar.
Inmutable pero no mucho
En los últimos años, hemos visto propuestas para fabricar sistemas operativos inmutables como OSTree. La idea de un sistema operativo inmutable es impedir hacer modificaciones fuera del directorio personal. Por lo general, cuando se instala un sistema operativo de tipo GNU/Linux, se nos permite implícitamente hacer con nuestro disco duro lo que se nos proponga, incluyendo modificar los archivos de carpetas especiales como /usr.
Y a pesar de que desde el punto de vista de la administración de sistemas, este es un paso que a veces hay que dar, por ejemplo, para instalar a mano una aplicación foránea que no se puede obtener fácilmente desde el gestor de paquetes, también es cierto que puede provocar desequilibrios en el sistema operativo. Archivos que se olvidan de eliminar al borrar una aplicación, o conflictos al actualizar porque de repente un programa instalado a mano no es compatible con una actualización de una dependencia de sistema.
Para establecer un término medio, VanillaOS trae una herramienta denominada almost. Con este sistema podemos alternar entre modo ro y modo rw. La principal diferencia es que mientras el sistema esté en modo ro, no será posible modificar la capa base del ordenador. Si en algún momento necesitamos tocar algún directorio del sistema, no obstante, podremos cambiar a modo rw y hacer nuestros cambios, volviendo a poner el sistema oprativo en modo ro en el siguiente arranque. De este modo nos lo tendremos que pensar un poco antes de hacer modificaciones, y el sistema se mantendrá mucho más estático.
VanillaOS también soporta el concepto de «capas», en el sentido de que mientras se aplican cambios, es posible tener un área de staging donde ensayar los cambios que se hagan al sistema antes de aplicarlo. Esto lo podemos utilizar para poner los archivos y ver el resultado que tendría al aplicarlo de forma definitiva. Eso sí, no es un concepto de capas como el que hay en OSTree ni mucho menos, por lo que una vez se aplique de forma definitivamente una capa, se introducen esos cambios en el sistema de archivos real sin vuelta atrás (salvo que lo hagamos a mano, claro).
Las opciones de VanillaOS preguntan qué tipo de sistema operativo se quiere tener, uno inmutable o uno no inmutable.
apx: instala paquetes de forma segura
Sabemos que no siempre es fácil encontrar software para algunas distribuciones GNU/Linux. Muchas distribuciones grandes hoy día usan herramientas como copr o PPA para poder hacer más flexible la obtención de software de terceros en un sistema. Sin embargo, esto a menudo suele ser un foco de problemas en tanto que esos paquetes pueden provocar que tarden más comandos como apt update, o incluso pueden provocar que varios paquetes se bloqueen por incompatibilidad.
Sin embargo, sabemos de sobra quién no tiene problemas de paquetes en sus repositorios, ¿no? Efectivamente, el sistema AUR de Arch Linux. De modo que VanillaOS trae un gestor de paquetes llamado apx, que aparte de ser otro frontend para interactuar con el apt-get del sistema operativo, nos permite algunas cosas especiales.
Por ejemplo, otra de las características de apx es que permite instalar paquetes en contenedores aislados. Con eso, evitaremos dañar el sistema principal al instalar y desinstalar cosas, ya que cabe la posibilidad de que con tanta instalación y desinstalación de cosas, se queden cosas a medio instalar. (¿A quién no le ha pasado que se queda algún paquete sin eliminar del todo porque deja algún archivo de configuración suelto o porque se instaló como recomendación y nunca se quitó?)
Esta característica, no obstante, no está disponible en este momento en máquinas virtuales, así que si apx detecta que se está ejecutando desde una máquina virtual o hipervisor como QEMU o VirtualBox, rechazará activar el soporte para contenedores. Si estás evaluando VanillaOS en una máquina virtual antes de decidirte a instalarlo o no, tendrás que prescindir de esta prueba.
