Cómo construir un paquete plano

Hace mucho tiempo, una distribución de Linux envió un sistema operativo junto con todos el software disponible para ello. No existía el concepto de software de "terceros" porque todo era parte de la distribución. Las aplicaciones no se instalaban tanto como se habilitaban desde un gran repositorio de software que tenía en uno de los muchos disquetes o, más tarde, CD que compraba o descargaba.

Esto se convirtió en algo aún más conveniente a medida que Internet se hizo omnipresente y nació el concepto de lo que ahora es la "tienda de aplicaciones". Por supuesto, las distribuciones de Linux tienden a llamar a esto un repositorio de software o simplemente repo para abreviar, con algunas variaciones de "marca", como Ubuntu Software Center o, con el minimalismo típico de GNOME, simplemente Software .

Este modelo funcionó bien cuando el software de código abierto todavía era una novedad y el número de aplicaciones de código abierto era un número en lugar de un teórico. número. En el mundo actual de GitLab, GitHub y Bitbucket (y muchos, muchos más), es casi imposible contar la cantidad de proyectos de código abierto, y mucho menos empaquetarlos en un repositorio. Ninguna distribución de Linux en la actualidad, ni siquiera Debian y su formidable grupo de mantenedores de paquetes, puede reclamar o esperar tener un paquete para cada proyecto de código abierto instalable.

Por supuesto, un paquete de Linux no tiene que estar en un repositorio para ser instalable. Cualquier programador puede empaquetar su software y distribuirlo desde su propio sitio web. Sin embargo, debido a que los repositorios se consideran parte integral de una distribución, no existe un formato de empaquetado universal, lo que significa que un programador debe decidir si lanzar un .deb o .rpm , o un script de compilación AUR, o un paquete Nix o Guix, o un script Homebrew, o simplemente un .tgz mayormente genérico archivo para /opt . Es abrumador para un desarrollador que vive y respira Linux todos los días, mucho menos para un desarrollador que solo trata de hacer el mejor esfuerzo posible para admitir un objetivo de código abierto y gratuito.

¿Por qué Flatpak?

El proyecto Flatpak proporciona un formato de empaque universal junto con un medio de distribución descentralizado, además de portabilidad y sandboxing.

• Universal Instale el sistema Flatpak y podrá ejecutar Flatpaks, independientemente de su distribución. No se requiere daemon o systemd. El mismo Flatpak se ejecuta en Fedora, Ubuntu, Mageia, Pop OS, Arch, Slackware y más.
• Descentralizado Los desarrolladores pueden crear y firmar sus propios paquetes y repositorios de Flatpak. No hay un depósito para solicitar que se incluya un paquete.
• Portabilidad Si tiene un Flatpak en su sistema y desea dárselo a un amigo para que pueda ejecutar la misma aplicación, puede exportar el Flatpak a una memoria USB.
• En espacio aislado Flatpaks utiliza un modelo basado en contenedores, lo que permite que existan múltiples versiones de bibliotecas y aplicaciones en un sistema. Sí, puede instalar fácilmente la última versión de una aplicación para probar mientras mantiene la versión anterior en la que confía.

Construyendo un Flatpak

Para construir un Flatpak, primero debe instalar Flatpak (el subsistema que le permite usar paquetes Flatpak) y la aplicación Flatpak-builder.

En Fedora, CentOS, RHEL y similares:

$ sudo dnf install flatpak flatpak-builder

En Debian, Ubuntu y similares:

$ sudo apt install flatpak flatpak-builder

También debe instalar las herramientas de desarrollo necesarias para compilar la aplicación que está empaquetando. Debido a la naturaleza del desarrollo de la aplicación que está empaquetando ahora, es posible que ya tenga un entorno de desarrollo instalado, por lo que es posible que no note que estos componentes son necesarios, pero si comienza a crear Flatpaks con Jenkins o desde contenedores internos, debe asegurarse de que sus herramientas de compilación son parte de su cadena de herramientas.

Para la compilación del primer ejemplo, este artículo asume que su aplicación usa GNU Autotools, pero Flatpak es compatible con otros sistemas de compilación, como cmake , cmake-ninja , meson , ant , así como comandos personalizados (un simple sistema de compilación, en la terminología de Flatpak, pero de ninguna manera esto implica que la compilación en sí sea realmente simple).

Directorio del proyecto

A diferencia de la estricta infraestructura de compilación de RPM, Flatpak no impone una estructura de directorio de proyectos. Prefiero crear directorios de proyectos basados ​​en dist paquetes de software, pero no hay ninguna razón técnica por la que no pueda integrar su proceso de compilación de Flatpak con su directorio de origen. Es técnicamente más fácil construir un Flatpak desde su dist sin embargo, y también es una demostración más fácil, así que ese es el modelo que usa este artículo. Configure un directorio de proyectos para GNU Hello, que sirva como su primer Flatpak:

$ mkdir hello_flatpak

$ mkdir src

Descarga tu fuente distribuible. Para este ejemplo, el código fuente se encuentra en https://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz .

$ cd hello_flatpak

$ wget https://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz

Manifiesto

La terminal de Linux

• Los 7 mejores emuladores de terminal para Linux
• 10 herramientas de línea de comandos para el análisis de datos en Linux
• Descargar ahora:hoja de referencia de SSH
• Hoja de trucos de comandos avanzados de Linux
• Tutoriales de línea de comandos de Linux

Un Flatpak se define mediante un manifiesto, que describe cómo compilar e instalar la aplicación que está entregando. Un manifiesto es atómico y reproducible. Sin embargo, un Flatpak existe en un contenedor de "caja de arena", por lo que el manifiesto se basa en un entorno mayormente vacío con una llamada de directorio raíz /app .

Los dos primeros atributos son el ID de la aplicación que está empaquetando y el comando que proporciona. El ID de la aplicación debe ser único para la aplicación que está empaquetando. La forma canónica de formular una ID única es usar un valor de triplete que consiste en la entidad responsable del código seguido del nombre de la aplicación, como org.gnu.Hello . El comando proporcionado por la aplicación es lo que escriba en un terminal para ejecutar la aplicación. Esto no implica que la aplicación esté diseñada para ejecutarse desde una terminal en lugar de un .desktop archivo en el menú Actividades o Aplicaciones.

En un archivo llamado org.gnu.Hello.yaml , introduce este texto:

id: org.gnu.Hello

command: hello

Un manifiesto se puede escribir en YAML o en JSON. Este artículo usa YAML.

A continuación, debe definir cada "módulo" entregado por este paquete Flatpak. Puede pensar en un módulo como una dependencia o un componente. Para GNU Hello, solo hay un módulo:GNU Hello. Las aplicaciones más complejas pueden requerir una biblioteca específica u otra aplicación completamente distinta.

modules:

  - name: hello

    buildsystem: autotools

    no-autogen: true

    sources:

      - type: archive

        path: src/hello-2.10.tar.gz

El buildsystem valor identifica cómo Flatpak debe construir el módulo. Cada módulo puede usar su propio sistema de compilación, por lo que un Flatpak puede tener varios sistemas de compilación definidos.

El no-autogen El valor le dice a Flatpak que no ejecute los comandos de configuración para autotools , que no son necesarios porque el código fuente de GNU Hello es producto de make dist . Si el código que está creando no tiene un formato fácil de compilar, es posible que deba instalar autogen y autoconf para preparar la fuente para autotools . Esta opción no se aplica en absoluto a los proyectos que no usan autotools .

El type El valor le dice a Flatpak que el código fuente está en un archivo, lo que desencadena las tareas de desarchivado necesarias antes de la construcción. La path apunta al código fuente. En este ejemplo, la fuente existe en el src directorio en su máquina de compilación local, pero en su lugar podría definir la fuente como una ubicación remota:

modules:

  - name: hello

    buildsystem: autotools

    no-autogen: true

    sources:

      - type: archive

        url: https://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz

Finalmente, debe definir la plataforma requerida para que la aplicación se ejecute y se compile. Los mantenedores de Flatpak proporcionan tiempos de ejecución y SDK que incluyen bibliotecas comunes, incluido freedesktop , gnome y kde . El requisito básico es el freedesk runtime y SDK, aunque esto puede ser reemplazado por GNOME o KDE, dependiendo de lo que necesite ejecutar su código. Para este ejemplo de GNU Hello, solo se requiere lo básico.

runtime: org.freedesktop.Platform

runtime-version: '18.08'

sdk: org.freedesktop.Sdk

Todo el manifiesto GNU Hello flatpak:

id: org.gnu.Hello

runtime: org.freedesktop.Platform

runtime-version: '18.08'

sdk: org.freedesktop.Sdk

command: hello

modules:

  - name: hello

    buildsystem: autotools

    no-autogen: true

    sources:

      - type: archive

        path: src/hello-2.10.tar.gz

Construyendo un Flatpak

Ahora que el paquete está definido, puede compilarlo. El proceso de compilación solicita a Flatpak-builder que analice el manifiesto y resuelva cada requisito:garantiza que la plataforma y el SDK necesarios estén disponibles (si no lo están, deberá instalarlos con el flatpak comando), desarchiva el código fuente y ejecuta el buildsystem especificado.

El comando para comenzar:

$ flatpak-builder build-dir org.gnu.Hello.yaml

El directorio build-dir se crea si aún no existe. El nombre build-dir es arbitrario; podrías llamarlo build o bld o penguin y puede tener más de un destino de compilación en el mismo directorio del proyecto. Sin embargo, el término build-dir es un valor que se usa con frecuencia en la documentación, por lo que usarlo como valor literal puede ser útil.

Probando su aplicación

Puede probar su aplicación antes o después de que se haya creado ejecutando el comando de compilación junto con --run y terminando el comando con el comando proporcionado por el Flatpak:

$ flatpak-builder --run build-dir \

org.gnu.Hello.yaml hello

Hello, world!

Embalaje de aplicaciones GUI con Flatpak

Empaquetando un simple hola mundo autónomo La aplicación es trivial y, afortunadamente, empaquetar una aplicación GUI no es mucho más difícil. Las aplicaciones más difíciles de empaquetar son aquellas que no dependen de bibliotecas y marcos comunes (en el contexto del empaquetado, "común" significa cualquier cosa no ya empaquetado por otra persona). La comunidad de Flatpak proporciona SDK y extensiones de SDK para muchos componentes que, de otro modo, habría tenido que empaquetar usted mismo. Por ejemplo, al empaquetar la implementación Java pura de pdftk , utilizo la extensión OpenJDK SDK que encontré en el repositorio Flatpak Github:

runtime: org.freedesktop.Platform

runtime-version: '18.08'

sdk: org.freedesktop.Sdk

sdk-extensions:

  - org.freedesktop.Sdk.Extension.openjdk11

La comunidad de Flatpak trabaja mucho en las bases necesarias para que las aplicaciones se ejecuten con el fin de facilitar el proceso de empaquetado para los desarrolladores. Por ejemplo, el juego Kblocks de la comunidad KDE requiere la plataforma KDE para ejecutarse, y eso ya está disponible en Flatpak. Los libkdegames adicionales La biblioteca no está incluida, pero es igual de fácil agregarla a su lista de modules como kblocks mismo.

Aquí hay un manifiesto para el juego Kblocks:

id: org.kde.kblocks

command: kblocks

modules:

- buildsystem: cmake-ninja

  name: libkdegames

  sources:

    type: archive

    path: src/libkdegames-19.08.2.tar.xz

- buildsystem: cmake-ninja

  name: kblocks

  sources:

    type: archive

    path: src/kblocks-19.08.2.tar.xz

runtime: org.kde.Platform

runtime-version: '5.13'

sdk: org.kde.Sdk

Como puede ver, el manifiesto sigue siendo sencillo y relativamente intuitivo. El sistema de compilación es diferente, y el tiempo de ejecución y el SDK apuntan a KDE en lugar de Freedesktop, pero la estructura y los requisitos son básicamente los mismos.

Sin embargo, debido a que es una aplicación GUI, se requieren algunas opciones nuevas. Primero, necesita un ícono para que cuando aparezca en el menú Actividades o Aplicación, se vea bien y sea reconocible. Kblocks incluye un ícono en sus fuentes, pero los nombres de los archivos exportados por un Flatpak deben tener el prefijo usando la ID de la aplicación (como org.kde.Kblocks.desktop ). La forma más fácil de hacer esto es cambiar el nombre del archivo directamente en la fuente de la aplicación, lo que Flatpak puede hacer por usted siempre que incluya esta directiva en su manifiesto:

rename-icon: kblocks

Otro rasgo único de las aplicaciones GUI es que a menudo requieren integración con servicios de escritorio comunes, como el propio servidor de gráficos (X11 o Wayland), un servidor de sonido como Pulse Audio y el subsistema de comunicación entre procesos (IPC).

En el caso de Kblocks, los requisitos son:

finish-args:

- --share=ipc

- --socket=x11

- --socket=wayland

- --socket=pulseaudio

- --device=dri

- --filesystem=xdg-config/kdeglobals:ro

Aquí está el manifiesto final y completo, usando URL para las fuentes para que pueda probarlo fácilmente en su propio sistema:

command: kblocks

finish-args:

- --share=ipc

- --socket=x11

- --socket=wayland

- --socket=pulseaudio

- --device=dri

- --filesystem=xdg-config/kdeglobals:ro

id: org.kde.kblocks

modules:

- buildsystem: cmake-ninja

  name: libkdegames

  sources:

  - sha256: 83456cec44502a1f79c0be00c983090e32fd8aea5fec1461fbfbd37b5f8866ac

    type: archive

    url: https://download.kde.org/stable/applications/19.08.2/src/libkdegames-19.08.2.tar.xz

- buildsystem: cmake-ninja

  name: kblocks

  sources:

  - sha256: 8b52c949e2d446a4ccf81b09818fc90234f2f55d8722c385491ee67e1f2abf93

    type: archive

    url: https://download.kde.org/stable/applications/19.08.2/src/kblocks-19.08.2.tar.xz

rename-icon: kblocks

runtime: org.kde.Platform

runtime-version: '5.13'

sdk: org.kde.Sdk

Para compilar la aplicación, debe tener instalados la plataforma KDE y SDK Flatpaks (versión 5.13 a partir de este escrito). Una vez que se ha creado la aplicación, puede ejecutarla usando el --run método, pero para ver el icono de la aplicación, debe instalarlo.

Distribuir e instalar un Flatpak que hayas construido

La distribución de flatpaks se realiza a través de repositorios.

Puede enumerar sus aplicaciones en Flathub.org, un sitio web de la comunidad pensado como técnicamente ubicación descentralizada (pero central en espíritu) para Flatpaks. Para enviar su Flatpak, coloque su manifiesto en un repositorio de Git y envíe una solicitud de extracción en Github.

Alternativamente, puede crear su propio repositorio utilizando flatpak build-export comando.

También puede simplemente instalar localmente:

$ flatpak-builder --force-clean --install build-dir org.kde.Kblocks.yaml

Una vez instalado, abre tu menú de Actividades o Aplicaciones y busca Kblocks.

Aprender más

El sitio de documentación de Flatpak tiene un buen tutorial para construir tu primer Flatpak. Vale la pena leerlo incluso si has seguido este artículo. Además de eso, los documentos brindan detalles sobre qué plataformas y SDK están disponibles.

Para aquellos que disfrutan aprendiendo de los ejemplos, hay manifiestos para todas las aplicaciones disponible en Flathub.

Los recursos para crear y usar Flatpaks son abundantes, y se puede decir que Flatpak, junto con los contenedores y las aplicaciones de espacio aislado, son el futuro, así que familiarícese con ellos, comience a integrarlos con sus canalizaciones de Jenkins y disfrute del empaquetado de aplicaciones de Linux fácil y universal.