Empaquetado en Profundidad

¿Es su aplicación apropiada?

La mayoría de las aplicaciones gráficas pueden ser hechas en Flatpak sin modificación, aunque la creación de un Flatpak de espacio aislado que evite que la aplicación haga cosas arbitrarias en la cuenta del usuario es más probable que requiera cambios de código.

Algunas cosas que podrían hacer una aplicación que no trabaje bien como un Flatpak:

  • Si instala servicios del sistema o cambia los archivos de configuración del sistema

  • Si necesita acceso a binarios u otros archivos en / usr que no se pueden empaquetar con la aplicación

Coseche una ID de aplicación

Para seleccionar una IDde aplicación apropiada:

  • Si la aplicación tiene ya un archivo de aplicación de este formato, esto es la ID de aplicación.

  • Si la aplicación exporta algunos servicios D-Bus (Buscar ficheros en /usr/share/dbus-1/services/ - aunque una aplicación puede exportar servicios D-Bus sin instalar un archivos de servicio) luego el prefijo del nombre de D-Bus debería coincidir con la ID de aplicación.

  • Si la aplicación está ya empaquetada en Flathub use, por favor, la misma ID de aplicación.

  • Si no es así, necesita inventar una ID de aplicación. Esta debería ser su mejor suposición posible sobre lo que usaría el upstream - si tiene su propio nombre de dominio, esa sería la base, de otro modo tome base en el hospedaje - e.g. com.github.<user/organization>.<Aplicación>. Advierta que la idea original de una ID de aplicación es un nombre reverso que esté bajo su control, si es posible, coordine con el upstream, pregunte si su elección es OK y pídales que renombren su archivo de escritorio y el icono para hacerlo coincidir.

Las aplicaciones sólo pueden exportar recursos bajo su ID de aplicación, de modo que el archivo de escritorio y el icono para la aplicación necesitan tener el nombre apropiado. El mejor sitio para implementar esto es el upstream. El segundo mejor sitio es en el paquete de la aplicación Fedora. Pero si esto no es posible, puede hacer esto en su container.yaml. Vea la sección [Renombres] abajo.

Versionando

Los Flatpaks en Fedora son diferentes de los paquetes are different from packages en el sentido de que no hay una versión de aplicación separada para F32, F33, rawhide, etc. En su lugar hay una única versión que es la última versión estable para todas las versiones de Fedora.

Un flatpak apunta a un tiempo de ejecución particular. Su versión estable debería, idealmente, apuntar a un tiempo de ejecución que corresponda a la última versión lanzada de Fedora. Si la versión estable lanzada upstream de la aplicación tiene dependencias que no están disponibles en la versión lanzada de Fedora y no se puede agrupar en su módulo de aplicación (e.g. requiere una versión más nueva del compilador C) entonces es aceptable que use la siguiente versión del tiempo de ejecución de Fedora, pero esto debería ser un caso inusual. Su aplicación puede estar basada en el módulo flatpak-runtime:f28, por ejemplo.

Las versiones del módulo y del contenedor para su lanzamiento estable deberían estar en la rama estable de su repositorio git y el arroyo del módulo estará en el arroyo estable.

container.yaml

finish-args

The flatpak/finish-args: section of your container.yaml determines what permissions the application will have.

Non-sandboxed application, application requires X, and accesses the network
flatpak:
    finish-args: >
        --share=network
        --socket=x11
        --filesystem=user
Sandboxed application
flatpak:
    finish-args: >
        --socket=wayland
        --socket=fallback-x11
Non-sandboxed application, application has wayland support, and uses DConf
flatpak:
    finish-args: >
         --filesystem=host
         --share=ipc
          --socket=fallback-x11
          --socket=wayland
          --socket=session-bus
          --filesystem=~/.config/dconf:ro
          --filesystem=xdg-run/dconf
          --talk-name=ca.desrt.dconf
          --env=DCONF_USER_CONFIG_DIR=.config/dconf

Renames

Many existing applications in Fedora do not have an application in standard form. You can add keys to your container.yaml to rename exported resources to match the application ID.

flatpak:
    rename-appdata-file: eog.appdata.xml
    rename-desktop-file: eog.desktop
    rename-icon: eog

The preferred way, however, is to fix the application ID in the RPM packaging, or even better, upstream. The reason this is better is that the system can understand the relationship between the two applications, and won’t show duplicate entries in GNOME Software or the installed application list.

Other keys

The complete list of supported keys from the Flatpak builder manifest file that you can add to the flatpak: section of container.yaml is:

  • appdata-license

  • appstream-compose

  • copy-icon

  • desktop-file-name-prefix

  • desktop-file-name-suffix

  • rename-appdata-file

  • rename-desktop-file

  • rename-icon

See the flatpak-manifest(5) manual page for documentation.