Linux Sin Humo (Publicaciones sobre package-management)

¿Qué es flatpak?

sebelk — Sat, 22 Jun 2024 20:11:07 GMT

Es conveniente y merecido que Flatpak tenga un post especialmente dedicado a él, más allá de su interacción con polkit que dejamos planteado en el post anterior.

Brevísimo repaso histórico

En agosto de 2007 el desarrollador sueco Alexander Larsson lanza su primer intento de empaquetar aplicaciones con todas sus dependencias. A fines de 2014 comienza a trabajar en el proyecto xdg-app, el cual cambia de nombre a Flatpak en 2016.

¿Qué es Flatpak?

Flatpak es un sistema para compilar, distribuir y ejecutar aplicaciones. Las aplicaciones se pueden compilar y distribuir independientemente del sistema en que se usan, y al ejecutarse están aisladas del mismo hasta cierto punto.

Cada aplicación está en un sandbox, de manera predeterminada solamente puede acceder al contenido del mismo. Cada programa en flatpak tiene acceso a

~/.var/app/$FLATPAK_ID, y $XDG_RUNTIME_DIR/app/$FLATPAK_ID.
De manera limitada a llamadas del sistema.
De manera limitada a la instancia de D-BUS.

Aun así, para ser realistas, las aplicaciones en general necesitan más permisos, en este caso se insta a los empaquetadores a que adviertan qué accesos necesitará la aplicación para que el usuario esté conciente de ello, tal como cuando se instala una app desde el Play Store de Android.

Flatpak ofrece un repositorio llamado Flathub. Nada impide que cualquier persona o proyecto (como es el caso de Fedora) tenga el suyo propio.

Flatpak usa OSTree (Fedora usa OCI) para distribuir y desplegar datos. OSTree es similar a Git pero está diseñado para hacer control de versiones de binarios y archivos grandes de datos. El uso de OSTree permite además que un mismo archivo sea usado por más de una misma aplicación, ahorrando de esta manera espacio en disco. Cada aplicación que se instala es almacenada en un repositorio local de control de versiones, y luego se mapea en el sistema de archivos local.

Los cambios entre las diferentes versiones de una aplicación se aplican en el filesystem mediante enlaces duros.

Por ejemplo, con el comando siguiente podemos ver log del último commit de una aplicación flatpak (Logseq): .

❯ ostree log --repo=/var/lib/flatpak/repo  deploy/app/com.logseq.Logseq/x86_64/stable
commit a54ee70b0ec9047c2083f77b9f9175e8e8edcac998e3be8d395009255a6a03f6
Parent:  8c36feebe7ea23654917f542eb5419b71426359a42165f53496c9d82049a6806
ContentChecksum:  4d06f4e875d0335f2ff1c7a30ffa5b200c9a3eb3aeb0b608588eadb045994b22
Date:  2024-06-09 07:22:27 +0000

    Remove screenshot locale (8a160109)

    Name: com.logseq.Logseq
    Arch: x86_64
    Branch: stable
    Built with: Flatpak 1.14.8

<< History beyond this commit not fetched >>

En realidad el comando mostrado es de bajo nivel solamente a los efectos de mostrar ostree como software subyacente, para obtener información a más alto nivel, es conveniente usar directamente el comando flatpak para obtener información de la aplicación:

> flatpak info com.logseq.Logseq 

Logseq - Connect your notes and knowledge

                 ID: com.logseq.Logseq
         Referencia: app/com.logseq.Logseq/x86_64/stable
       Arquitectura: x86_64
               Rama: stable
            Versión: 0.10.9
           Licencia: AGPL-3.0-or-later
             Origen: flathub
          Colección: org.flathub.Stable
        Instalación: system
          Instalada: 437,7 MB
Tiempo de ejecución: org.freedesktop.Platform/x86_64/23.08
                Sdk: org.freedesktop.Sdk/x86_64/23.08

             Commit: a54ee70b0ec9047c2083f77b9f9175e8e8edcac998e3be8d395009255a6a03f6
              Padre: 8c36feebe7ea23654917f542eb5419b71426359a42165f53496c9d82049a6806
             Asunto: Remove screenshot locale (8a160109)
              Fecha: 2024-06-09 07:22:27 +0000

Comparación entre dnf, apt y flatpak

Flatpak está pensado para todo tipo de aplicaciones de escritorio y se esfuerza por ser tan neutral como sea posible en cuanto a los métodos que usa para compilar aplicaciones.

Además, flatpak proporciona actualizaciones atómicas, rollback y consistencia post-instalación.

El siguiente cuadro nos ayuda a ver las diferencias con los dos gestores populares de paquetes: dnf y apt.

Característica	DNF	APT	Flatpak
Distribución Principal	Fedora, RHEL, CentOS	Debian, Ubuntu	Varias distribuciones de Linux
Formato de Paquete	RPM	DEB	OSTree, Flatpak Bundle
Gestión de Dependencias	Manejo automático de dependencias	Manejo automático de dependencias	Manejo dentro del sandbox
Aislamiento	No	No	Sí, aplicaciones ejecutadas en sandbox
Instalación de Aplicaciones	Desde repositorios específicos del sistema	Desde repositorios específicos del sistema	Desde repositorios centralizados (Flathub) y repositorios personalizados
Actualizaciones	`dnf update`	`apt update && apt upgrade`	`flatpak update`
Permisos de Instalación	Requiere permisos de root	Requiere permisos de root	Puede instalarse sin permisos de root
Compatibilidad entre Distros	Limitada a sistemas basados en RPM	Limitada a sistemas basados en DEB	Compatible con múltiples distribuciones
Seguridad	Depende de la configuración del sistema	Depende de la configuración del sistema	Sandboxing y permisos controlados por portales
Facilidad de Uso	Interfaz de línea de comandos	Interfaz de línea de comandos	Interfaz de línea de comandos y GUI
Espacio de Disco	Compartido entre aplicaciones	Compartido entre aplicaciones	Deduplicación y compartición de runtimes
Formato de Archivo Individual	No aplica	No aplica	Flatpak Bundle (`.flatpak`)
Desventajas	Depende de la política de la distro	Dependencia de la política de la distro	Las aplicaciones pueden tener un mayor tamaño inicial
Compatibilidad con Aplicaciones Antiguas	Sí, con soporte de versiones específicas	Sí, con soporte de versiones específicas	Generalmente más adecuado para nuevas aplicaciones
Desarrollo y Mantenimiento	Desarrollado por el proyecto Fedora	Desarrollado por el proyecto Debian	Desarrollado por el proyecto Flatpak, con apoyo de Red Hat y GNOME
Adopción	Usado por muchas distribuciones y entornos de escritorio	Usado principalmente en Debian, Ubuntu y derivadas	Usado en diversas distribuciones, especialmente para aplicaciones portátiles
Ejemplo de Comando de Instalación	`dnf install gedit`	`apt install gedit`	`flatpak install flathub org.gnome.Gedit`

Inconvenientes para usuarios y desarrolladores de aplicaciones Linux

Si bien Linux mejoró significativamente en cuando a usabilidad y experiencia de usuario en los últimos años, hay obstáculos tanto para usuarios como para desarrolladores:

Una aplicación para un entorno de escritorio en Linux se debe empaquetar para que esté disponible (como Debian, Fedora, Ubuntu, Arch Linux, etc.), y asegurarse de que cumpla con los requisitos específicos de cada sistema de paquetes (deb, rpm, etc.). Esto requiere un esfuerzo considerable para mantener múltiples versiones y asegurarse de que cada paquete funcione correctamente en su respectiva distribución. Todo esto demanda o más tiempo o bien más gente idónea dedicada en la tarea de crear y mantener paquetes.
Si un usuario quiere usar aplicación que no está empaquetada en la distribución, tendrá que realizar algún paso extra, que van desde operaciones relativamente sencillas como bajar un ejecutable (darle permisos, ubicarlo en un directorio del PATH, etc.), hasta procedimientos bastante más complejos y fuera del interés y conocimiento de un usuario final como puede ser compilar el programa.
Una distribución de soporte a largo plazo como Debian Stable no posee versiones actualizadas de la mayoría de las aplicaciones. Por lo tanto un usuario tiene que elegir estabilidad a cambio de software un tanto anticuado.

Flatpak tiene como propósito justamente eliminar esas barreras. Gracias a Flatpak un usuario podrá instalar una aplicación como Logseq aun cuando no esté incluida en los repositorios de su distribución, o instalar una versión reciente de Kdenlive en Debian Stable.

En la actualidad existen distribuciones con la mirada puesta en la innovación que se benefician de Flatpak, por ejemplo:

Características de flatpak

Analicemos la app ONLYOFFICE en flatpak:

flatpak info org.onlyoffice.desktopeditors

ONLYOFFICE Desktop Editors - Office productivity suite

                 ID: org.onlyoffice.desktopeditors
         Referencia: app/org.onlyoffice.desktopeditors/x86_64/stable
       Arquitectura: x86_64
               Rama: stable
            Versión: 8.0.1
           Licencia: AGPL-3.0-only
             Origen: flathub
          Colección: org.flathub.Stable
        Instalación: system
          Instalada: 863,8 MB
Tiempo de ejecución: org.freedesktop.Platform/x86_64/23.08
                Sdk: org.freedesktop.Sdk/x86_64/23.08

             Commit: c9f73db43c9639df65e597108eb4c685025fe484fde05f73f650d05f9ea28512
              Padre: a38db7bbfaa18eda6d26e9d113ce850c077bf533d9ebf5aa7e34988a58b91b28
             Asunto: Update version to 8.0.1 (#117) (a88ad400)
              Fecha: 2024-03-04 15:34:56 +0000

La aplicación ONLYOFFICE usa como runtime org.freedesktop.Platform/x86_64/23.08. El runtime org.freedesktop.Platform/x86_64/23.08 es un entorno estandarizado y versionado que provee FreeDesktop.org para ejecutar aplicaciones de escritorio en Linux. Incluye una colección de librerías y servicios comunes, que aseguran la compatibilidad y la estabilidad entre las diferentes distribuciones de Linux. Este runtime está compilado específicamente para arquitecturas de 64-bit y fue actualizado o liberado en agosto de 2023.

Los runtimes no dependen ni de una distribución ni de una versión en particular de una distribución. Y una aplicación instalada en flatpak será exactamente igual no importa si se instala en Debian o en Fedora. Una aplicación como GIMP, empaquetada como Flatpak, debería proporcionar la misma funcionalidad principal y experiencia de usuario tanto en Debian como en Fedora, dado que todas las dependencias y configuraciones críticas se gestionan dentro del contenedor Flatpak. Desde luego, hay diferencias potenciales: Si una aplicación Flatpak utiliza características específicas del sistema, como integraciones con servicios de notificación de escritorio, la forma en que estas integraciones funcionan puede variar ligeramente entre GNOME en Fedora y KDE en Debian.

Objeciones en cuanto a la seguridad

Han existido críticas severas a la seguridad de flatpak, en especial por el sitio anónimo Flatkill. El siguiente cuaddro es un resumen de los argumentos en contra y favor de Flatpak en cuanto a este tema:

Objeción de Seguridad	Descripción	Respuesta / Acción Tomada
Sandboxing Ineficaz	Muchas aplicaciones en Flathub tienen permisos amplios como `filesystem=host` o `filesystem=home`, lo que permite acceso completo al sistema de archivos del usuario.	Flatpak ha mejorado la transparencia sobre los permisos de las aplicaciones y trabaja en fortalecer el modelo de sandboxing. Se han introducido portales para permitir el acceso controlado a los recursos del sistema. Flatpak Documentation
Actualizaciones de Seguridad Retrasadas	Algunas aplicaciones y runtimes en Flatpak no reciben actualizaciones de seguridad oportunas, lo que deja a los usuarios expuestos a vulnerabilidades conocidas.	La herramienta flatpak-external-data-checker automatiza la verificación de fuentes externas y la generación de solicitudes de fusión cuando se encuentran actualizaciones. Al implementar f-e-d-c, los desarrolladores pueden asegurar que las aplicaciones en Flathub se mantengan actualizadas más fácilmente y de manera más eficiente, lo que reduce el tiempo de espera para las actualizaciones de los usuarios finales
Integración Limitada del Escritorio	Problemas con la integración de aplicaciones Flatpak en escritorios Linux, como la falta de soporte para configuraciones de fuentes y temas de escritorio.	Se han mejorado los mecanismos de integración de escritorio, incluyendo mejor soporte para fuentes y temas en KDE y GNOME. Flatpak sigue trabajando en mejorar la compatibilidad con configuraciones del sistema host.)
Explotación Local de Root	Riesgo de explotación de root local debido a aplicaciones Flatpak instaladas con permisos suid.	Flatpak utiliza nuevas APIs de libostree para rechazar cualquier archivo con permisos suid o de escritura mundial al instalar aplicaciones.
Gestión de Permisos Confusa para el Usuario	Los usuarios pueden ser engañados por íconos y descripciones que indican un falso sentido de seguridad sobre las aplicaciones sandboxed.	Flatpak ha mejorado la interfaz de usuario para mostrar de manera más clara los permisos que solicita cada aplicación, ayudando a los usuarios a tomar decisiones informadas sobre las aplicaciones que instalan.

¿Cómo hace flatpak para no pedirle a un usuario de un grupo administrativo que se autentique nuevamente?

En el post anterior vimos como funciona polkit. Flatpak se vale de polkit para facilitar la instalación de paquetes por parte de usuarios con permisos administrativos. Basta con mirar el archivo /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules.

polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.Flatpak.app-install" ||
         action.id == "org.freedesktop.Flatpak.runtime-install"||
         action.id == "org.freedesktop.Flatpak.app-uninstall" ||
         action.id == "org.freedesktop.Flatpak.runtime-uninstall" ||
         action.id == "org.freedesktop.Flatpak.modify-repo") &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }

    return polkit.Result.NOT_HANDLED;
});

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.Flatpak.override-parental-controls") {
            return polkit.Result.AUTH_ADMIN;
    }

    return polkit.Result.NOT_HANDLED;
});

Este archivo tiene dos reglas:

Permite a los usuarios del grupo "wheel", que están loogoueados localmente y tienen una sesión activa instalar, desinstalar, y modificar aplicaciones y repositorios sin autenticación adicional.
No se pueden pasar por arriba de los controles parentales sin autenticarse con una cuenta de usuario administrativa.

Para ambos casos, si las condiciones no se cumplen, el resultado dependerá de otras reglas o de la regla predeterminada.

Para terminar...

Flatpak elimina barreras y obstáculos tanto para desarrolladores como para usuarios finales. Para los primeros, significa les ofrece la posibilidad de poner aplicaciones disposición de cualquier distribución de Linux. Para los segundos representa una mayor facilidad para obtener los programas que están necesitando.

Fuentes y Más Recursos

Upstream, Appstream y DownStream

sebelk — Fri, 25 Dec 2020 22:43:16 GMT

La manera tradicional que tenemos para instalar software en los entornos de escritorio de Linux es usando las herramientas de línea de comando o tal vez herramientas gráficas tales como Synaptic y dnfdragora.

Este tipo de instalación a la que los usuarios de Linux de unos cuantos años estamos acostumbrados no es ni más fácil ni más difícil que buscar aplicaciones, bajarlas y correr un instalador y presionando los botones "Next", "Next"...

Sin embargo, la mayoría de los usuarios finales en la actualidad suelen instalar aplicaciones desde centros de software desde teléfonos celulares, los famosos App Stores, tales como Google Play y Apple App Store.

Como respuesta los dos entornos de escritorio principales de Linux cuentan con herramientas similares: Software (GNOME) y Discover (Plasma) para crear una experiencia de usuario similar:

Este clase de programas usan no solamente el sistema de paquetes de la distribució (sea tanto repositorios oficiales como así también de teceros), sino además, pueden usar sistemas como flatpak y snapcraft.

Debajo de estas herramientas tenemos a AppStream la cual proporciona metadatos universales de aplicaciones. Se trata de una especificación de freedesktop.org que resulta beneficiosa tanto para desarrolladores como para usuarios finales.

Photo by Good Free Photos on Unsplash

Puede tratar de manera específica a cada componente de acuerdo a su tipo: aplicación de escritorio, complemento, codec, fuente, etc.

Estos metadatos se guardan en archivos XML. En Fedora, por ejemplo podemos encontrar estos archivos en:

/usr/share/app-info/
/usr/share/metainfo/

De acuerdo a las directrices para empaquetar software de Fedora, toda aplicación con interfaz gráfica tiene que tener un archivo *.appdata.xml

Debian usa un único archivo YAML en lugar de XML, en Debian Buster para plataforma AMD64 se encuentra en /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_dep11_Components-amd64.yml.gz.

Estos archivos suelen contener un identificador, nombre, resumen, icono que representa al componente, descripción, categoría, información de versiones. También puede indicar si el componente es esencial para el funcionamiento de un entorno de escritorio y capturas de pantalla. Incluso ofrece el soporte para que el usuario califique la aplicación.

Es muy importante contar con la metadata de las aplicaciones de modo que appstream y programas como Discover y Software funcionen correctamente. Por ejemplo, en el caso del repositorio rpmfusion es necesario instalar un paquete aparte: dnf install rpmfusion-free-appstream-data.noarch

En la actulidad un usuario puede buscar una determinada aplicación del proyecto KDE e instalarla desde KDE's Applications. Supongamos que encuentra a Calligra Stage y decide instalarla:

Es decir, se puede ver que tiene el siguiente URI: appstream://org.kde.calligrastage.desktop al ser una herramienta totalmente agnóstica puede usar tanto un repositorio tradicional, como los de flatpak y snapcraft. Es decir, es importante entender que appstream no es un método nuevo de empaquetar software o un nuevo tipo de repositorio. Si la aplicación no está en los repositorios mencionados, obviamente la instalación fallará.

Es decir, luego en Discover:

También, podríamos instalarla directamente usando appstream:

appstreamcli install org.kde.calligrastage.desktop

Para ver el estado:

Podemos ver entonces que appstream funciona como un puente bidireccional, los proyectos upstream pueden facilitar el empaquetamiento y disponibilidad de aplicaciones, y cada distribución (downstream) puede dar a conocer de una manera mucho más amigable el software para los usuarios finales creando un círculo virtuoso.

Fuentes y Más Recursos

Sistemas de construcción de paquetes (Parte 4)

sebelk — Sun, 06 Oct 2019 16:31:54 GMT

De acuerdo a los resultados, podría verse que autotools sigue siendo el “Build System” predominante. Otros paquetes todavía usan un makefile plano, tal vez merezcan un análisis aparte.

Limitaciones de estas estadísticas:

Se confía en que siempre que se usa CMakeList.txt se usa cmake.
Se confía en que siempre que existan los archivos configure.ac o configure.in y Makefile.am o Makefile.in y se encuentra en el archivo spec el procedimiento ./configure && make se usan las autotools
Hubo 1 (un) archivos que no pudieron ser inspeccionados por dtrx porque tenía la extensión incorrecta

Actualización 2019

Las dos cosas más notables son la reducción del uso de autotools y por otro lado la aparición de sistemas alternativos de construcción (casi un 70%).

Sistema de construcción de paquetes (Parte 3)

Sistemas de contrucción de paquetes (Parte 2)

sebelk — Sun, 06 Oct 2019 15:36:08 GMT

El siguiente paso fue descomprimir de manera recursiva los paquetes, para luego poder inspeccionar en ellos. Lo hice con una herramienta poco conocida dtrx. Lo interesante de este script de python es que puede realizar extracciones recursivas y de acuerdo a la extensión del archivo utiliza el software de extracción necesario. Esperemos que pronto esté en los repositorios de Fedora (ver la solicitud en Red Hat Bugzilla).

Una vez descompridos todos los paquetes, se corrió el siguiente script

#! /bin/bash #Very simple script to get Build System Statistc dir=1 rm -f /tmp/ant /tmp/cmake /tmp/autotools /tmp/makefile /tmp/autoconf /tmp/autotools_procedure for i in (find dir -maxdepth 1 -mindepth 1 -type d) do ls -R1 i | grep -q -P -m1 "^configure.(ac|in)" if [[ ? -eq 0 ]];then ls -R1 i | grep -P -q -m1 "^Makefile\.(am|in)" if [[ ? -eq 0 ]];then echo "{i##/}" >> /tmp/autotools 2>/dev/null cant_autotools=(($cant_autotools+1)) else echo "{i##/}" >> /tmp/autoconf 2>/dev/null cant_autoconf=(($cant_autoconf+1)) fi fi #cmake ls -R1 i | grep -q -m1 CMakeLists.txt if [[ ? -eq 0 ]];then cant_cmake=((cant_cmake+1)) echo "{i##/}" >> /tmp/cmake 2>/dev/null fi #Plain makefile ls -R1 i | grep -q -P -m1 "^configure\.(ac|in)" if [[ ? -ne 0 ]];then ls -R1 i | grep -q -P -m1 "^(Makefile.(am|in)|CMakeLists.txt)" if [[ ? -ne 0 ]];then ls -R1 i | grep -q -P -m1 "^Makefile" if [[ ? -eq 0 ]];then cant_makefile=((cant_makefile+1)) echo "${i##/}" >> /tmp/makefile 2> /dev/null fi fi fi find i -name "*.spec" | xargs pcregrep -q -M "%build(.*\n)*(./|%)configure.*\n(.*\n)*make(.*\n)*%install" if [[ ? -eq 0 ]];then cant_autotools_build_section=(($cant_autotools_build_section+1)) echo "{i##*/}" >> /tmp/autotools_procedure fi done echo "###Resultados###" [ -f /tmp/autotools ] && echo -e "There are cant_autotools with autotools:\n\n(sort /tmp/autotools)\n\n" [ -f /tmp/cmake ] && echo -e "cant_cmake with cmake:\n\n(sort /tmp/cmake)\n\n" [ -f /tmp/makefile ] && echo -e "cant_makefile with makefile:\n\n(sort /tmp/makefile)\n\n" [ -f /tmp/autoconf ] && echo -e "cant_autoconf with only autoconf:\n\n(sort /tmp/autoconf)\n\n" [ -f /tmp/autotools_procedure ] && echo -e "cant_autotools_build_section with only autotools_build_section\n\n(sort /tmp/autotools_procedure)"

En la siguiente parte veremos los resultados….

10 Trucos poderosos con RPM

sebelk — Mon, 02 Sep 2019 12:20:07 GMT

Nota: Los nombres de los paquetes están puestos como ejemplos

1. Mostrar los tipos de archivos que contiene un paquete

rpm -q --fileclass zram

2. Mostrar el orden y fecha en que fueron instalados los paquetes

rpm -qa --last --qf '%{name}\n'|tac

3. Mostrar los nombres (y solamente los nombres!) de todos los paquetes instalados

rpm -qa --qf '%{name}'|sort

4. Ver los cambios que tiene un paquete en su versión

rpm -q --changes neovim|less

5. Ver lo que hace un paquete al instalarse/desinstalarse

rpm -q --scripts mariadb-server

6. Restaurar los permisos predeterminados

rpm --restore mariadb

Este comando restaura los permisos, propietarios y capacidades de los archivos. No reestablece marcas de tiempo.

7. Extraer los archivos de un paquete

cd /tmp
dnf download mariadb-server # Aquí puede usarse también yumdownloader
mkdir mariadb-server
mv mariadb-server*rpm mariadb-server
cd mariadb-server
rpm2cpio mariadb-server  | cpio -imdv

8. Listar los paquetes duplicados

rpm -qa --dupes

9. Encontrar el archivo de licencia del paquete

rpm -qL firefox

10. Operar por red

Las operaciones con rpm se pueden realizar también con direcciones remotas, como se muestra en la imagen inferior:

Más información

rpm.org - Home

Sistemas de construcción de paquetes (Parte 3)

sebelk — Wed, 06 Mar 2019 16:00:55 GMT

Los resultados son:

37 paquetes con autotools: Son paquetes en los cuales se encontaron los archivos configure.ac o configure.in y Makefile.am o Makefile.in

5 paquetes con cmake: Son paquetes que tienen el archivo CMakeLists.txt

21 paquetes con “sólo” [Mm]akefile, que no tienen los archivos arriba mencionados

36 paquetes con “autotools procedure”: Paquetes que siguen la secuencia “./configure && make”

Resultado actualizado a octubre 2019 (con otra muestra de paquetes)

11 paquetes con autotools: Son paquetes en los cuales se encontaron los archivos configure.ac o configure.in y Makefile.am o Makefile.in

6 paquetes con cmake: Son paquetes que tienen el archivo CMakeLists.txt

11 paquetes con “sólo” [Mm]akefile, que no tienen los archivos arriba mencionados

14 paquetes con “autotools procedure”: Paquetes que siguen la secuencia “./configure && make”

En la próxima las conclusiones

Sistemas de Construcción de Paquetes (Parte 1)

sebelk — Sat, 12 Mar 2011 16:17:45 GMT

Dentro de los sistemas de construcción de paquetes en los sistemas estilo Linux, el más conocido de ellos el GNU Build System, aka autotools.

Las autotools tienen la reputación de ser difíciles y abrumadoramente barrocas. Es por eso que han surgido sistemas alternativos siendo tal vez la más más popular cmake.

Es por ello que me propuse hacer una estadística, tal vez bastante rudimentaria acerca de los sistemas de construcción de paquetes.

Lo primero que hice fue ejecutar algo como esto:
repoquery -a --disablerepo=livna,rpmfusion-free,rpmfusion-free-updates --source | uniq | shuf -n 101 | sed ‘s/.src.rpm//g’ | xargs yumdownloader --source

Con esto se consigue una muestra de 101 paquetes de los repositorios oficiales de Fedora 14.

Los paquetes son:

ailurus-10.10.3-1.fc14.src.rpm alsa-oss-1.0.17-4.fc12.src.rpm aplus-fsf-4.22.4-19.fc12.src.rpm ar9170-firmware-2009.05.28-2.fc13.src.rpm azureus-4.5.1.0-1.fc14.src.rpm bitfrost-1.0.10-1.fc14.src.rpm bwidget-1.9.0-1.fc13.src.rpm cfitsio-3.250-5.fc14.src.rpm congruity-14-1.fc13.src.rpm dogtag-pki-ra-ui-1.3.2-1.fc14.src.rpm drascula-international-1.0-3.fc12.src.rpm dump-0.4-0.8.b43.fc14.src.rpm dumpet-2.1-1.fc14.src.rpm dx-4.4.4-16.fc14.2.src.rpm easystroke-0.5.3-2.fc14.src.rpm eblook-1.6.1-10.fc14.src.rpm eclipse-jgit-0.10.1-1.fc14.src.rpm emacs-common-tuareg-1.45.6-9.fc12.src.rpm emacs-common-w3m-1.4.398-0.4.20100714cvs.fc14.src.rpm emacspeak-29.0-3.fc12.src.rpm fedora-packager-0.5.5.0-2.fc14.src.rpm FlightGear-2.0.0-4.fc14.src.rpm fmtools-2.0.1-2.fc13.src.rpm func-0.25-3.fc14.src.rpm gambas2-2.22.0-1.fc14.src.rpm gbirthday-0.6.5-2.fc14.src.rpm gedit-plugins-2.31.6-1.fc14.src.rpm gfs-pyrsos-fonts-20090618-3.fc13.src.rpm globus-gatekeeper-5.5-2.fc14.src.rpm globus-gram-job-manager-10.59-2.fc14.src.rpm globus-gram-job-manager-setup-sge-2.5-1.fc14.src.rpm gmm-4.0.0-1.fc14.src.rpm gnomeradio-1.8-6.fc14.src.rpm html2text-1.3.2a-6.fc13.src.rpm i3lock-1.0-4.20100320git.fc14.src.rpm isync-1.0.4-6.fc12.src.rpm javasqlite-20100727-1.fc14.src.rpm kdetv-0.8.9-13.fc12.src.rpm kmid2-2.3.0-2.fc14.src.rpm lcms2-2.1-1.fc14.src.rpm libfreebob-1.0.11-6.fc12.src.rpm libgalago-0.5.2-9.fc12.src.rpm libmusicbrainz3-3.0.3-2.fc14.src.rpm libotr-3.2.0-5.fc14.src.rpm lilypond-2.13.39-3.fc14.src.rpm makebootfat-1.4-11.fc14.src.rpm man-pages-cs-0.18.20090209-9.fc14.src.rpm metromap-0.1.2-5.fc14.src.rpm mono-basic-2.6.2-1.fc14.src.rpm mysql-5.1.55-1.fc14.src.rpm mysql-connector-c++-1.1.0-0.4.bzr895.fc14.src.rpm nedit-5.5-23.fc14.src.rpm nemiver-0.7.3-3.fc14.src.rpm nntpgrab-0.6.91-2.fc14.src.rpm nogravity-2.00-11.fc13.src.rpm ocaml-lacaml-5.4.7-2.fc13.src.rpm ogre-1.6.4-5.fc13.src.rpm openjpeg-1.3-10.fc14.src.rpm orage-4.6.1-2.fc13.src.rpm pam_abl-0.2.3-8.fc12.src.rpm perl-Catalyst-View-PDF-Reuse-0.03-4.fc14.src.rpm perl-CGI-Session-4.35-5.fc14.src.rpm perl-Color-Calc-1.061-2.fc14.src.rpm perl-Inline-0.46-1.fc14.src.rpm perl-Mixin-Linewise-0.003-2.fc14.src.rpm perl-MooseX-MethodAttributes-0.24-1.fc14.src.rpm perl-Net-FTPServer-1.122-9.fc14.src.rpm perl-Net-Patricia-1.19-1.fc14.src.rpm perl-Package-Stash-XS-0.19-1.fc14.src.rpm perl-Regexp-Assemble-0.34-5.fc14.src.rpm perl-String-Escape-2010.002-4.fc14.src.rpm perl-Text-Kakasi-2.04-13.fc14.src.rpm perl-UNIVERSAL-exports-0.05-8.fc14.src.rpm php-gettext-1.0.9-2.fc13.src.rpm php-pear-CodeGen-1.0.7-3.fc14.src.rpm postal-0.70-6.fc14.src.rpm pyclutter-gtk-0.10.0-2.fc14.src.rpm pyflakes-0.4.0-4.fc14.src.rpm python-billiard-0.3.1-2.fc14.src.rpm python-rabbyt-0.8.3-2.fc14.src.rpm python-zope-sqlalchemy-0.6-1.fc14.src.rpm redir-2.2.1-4.fc12.src.rpm rhncfg-5.9.22-2.fc14.src.rpm R-nws-1.7.0.1-1.fc14.src.rpm rubygem-shotgun-0.4-1.fc14.src.rpm R-zoo-1.6-3.fc14.src.rpm sarai-fonts-1.0-9.fc14.src.rpm sblim-cmpi-params-1.2.6-1.fc13.src.rpm scim-1.4.9-6.fc13.src.rpm shed-1.15-5.fc12.src.rpm sugar-tamtam-0-0.6.20100201git.fc14.src.rpm Thunar-1.0.2-3.fc14.src.rpm veusz-1.9-2.fc14.src.rpm vhd2vl-2.3-1.fc14.src.rpm virt-what-1.3-3.fc14.src.rpm w3m-0.5.2-18.fc14.src.rpm wannier90-1.2-2.fc13.src.rpm writer2latex-1.0.2-3.fc14.src.rpm ws-jaxme-0.5.1-4.4.fc12.src.rpm xmlfy-1.5.3-1.fc14.src.rpm xpaint-2.9.8.1-1.fc14.src.rpm

Esta historia continúa

Autotools: Detrás de los famosos 3 pasos

sebelk — Sat, 05 Mar 2011 16:07:16 GMT

La mayoría de los usuarios con conocimiento intermedios (o más) en Linux y sistemas similares habrá alguna vez compilado alguna vez un paquete con la siguiente secuencia de comandos:

./configure

make

make install

Lo que tal vez no muchos conocen es qué herramientas permiten realizar eso y menos aun como se hace para construir los famosos archivos con extensión .tar.gz o .tar.bz2.

Autotools

Se conoce popularmente como autotools al GNU Build System, es decir al conjunto de herramientas para construir paquetes instalables de software.

Si bien un aplicación o una librería puede ser instalada – al menos en principio – a partir de un relativamente sencillo Makefile, tiene en principio dos grandes limitaciones, puede resultar poco flexible para el usuario instalador y puede resultar poco portable.

Las autotools se usan para estandarizar el proceso de instalación. Si bien la curva de aprendizaje de estas herramientas es algo empinada, proporciona una sistematización en la instalación de software a partir de código fuente.

Si bien se han creado con el tiempo algunos sistemas de construcción de paquetes alternativos en los sistemas operativos Linux y similares, es la suite preferida de una gran cantidad de proyectos open source.

De ahí que la secuencia de instalación ./configure && make && make install sea ampliamente conocido por los usuarios de sistemas operativos estilo Linux.

Componentes principales de autotools

autoconf

Crea el célebre script de alta portabilidad configure a partir de un archivo de macros M4. El script configure permite:

Personalizar la compilación (por ej: deshabilitar soporte para mysql)
Verificar que los archivos necesarios para compilar están presentes en el sistema
Imprimir mensajes descriptivos en cada caso
Crear un archivo Makefile

automake

Es un script de perl que a partir de un archivo “template” crea un archivo Makefile.in que genera archivos que permite crear archivos Makefile compatibles con GNU Coding Standards.^¹

libtool

Simplifica la creación de librerías (en particular de las dinámicas). Esta herramienta permite crear un nivel de abstracción del tipo de host que se está utilizando y permite al usuario compilar librerías con el mismo método de los tres pasos nombrados con anterioridad.

Resumen

Muy sintética y simplificadamente, la tarea del “maintainer” del paquete es crear de manera consistente archivos configura.ac (para autoconf), Makefile.am (para automake), además de echar mano de ser necesario de marcos M4 para resolver la realización de una tarea (por ejemplo verificar la existencia un determinado header).

Es un sistema que apunta a ser lo más portable posible y hacer previsible y flexible la tarea de instalar paquetes fuente al usuario.

El objetivo principal es hacerle la vida más fácil al usuario antes que al maintainer.

Desde luego, el usuario final rara vez compilará un programa. Sin embargo, crear un paquete instalable a partir del código fuente es el paso previo para crear paquetes ya compilados generalmente en formato RPM o Debian, dependiendo de la distribución. Y las autotools juegan un rol importante en esa etapa intermedia.

Los famosos 3 pasos

1http://www.gnu.org/prep/standards/standards.html

Usuario final: ¿A qué nos referimos? is licensed under a Creative Commons Atribución-CompartirDerivadasIgual 2.5 Argentina License. La manera de reconocer los créditos es citando la URL de este sitio.

Sistemas de construcción de paquetes

sebelk — Thu, 03 Mar 2011 07:05:43 GMT

De 100 paquetes de fedora, 39 usan autotools.

26 Development/Libraries
13 System Environment/Libraries
9 Development/Languages
9 Applications/Internet
7 Applications/System
4 User Interface/Desktops
3 User Interface/X
3 System Environment/Daemons
3 System Environment/Base
3 Development/Tools
3 Applications/Multimedia
3 Amusements/Games
2 Applications/Text
2 Applications/Productivity
2 Applications/File
1 User Interface/X Hardware Support
1 Development/Libraries/Java
1 Applications/Publishing
1 Applications/Engineering
1 Applications/Emulators
1 Applications/Editors
1 Applications/Databases

Compilar en diferentes directorios

sebelk — Fri, 01 Oct 2010 09:11:57 GMT

Compilar en diferentes directorios

mkdir custombuild

cd custombuild

./configure $CUSTOMFLAGS

Cambiarle el nombre a un programa

./configure --program-transform-name=PROGRAM