Changes/Graphical Applications as Flatpaks

Graphical Applications as Flatpaks

Summary

This change is to enable package maintainers to build Flatpaks of their applications and make those Flatpaks available for installation.

Owner

• Name: Owen Taylor
• Email: otaylor@redhat.com
• Release notes owner:
• Responsible WG: Workstation

Current status

• Targeted release: F27 (initial), F28 (complete)
• Last updated: 2017-06-13
• Tracker bug: <will be assigned by the Wrangler>

Detailed Description

This change is to enable package maintainers to build Flatpaks of their applications and make those Flatpaks available for installation.

The change will build on the work of Fedora Modularity - the Flatpak runtime will be a module and each application will be a module. The creation of the Flatpaks themselves will follow the model of containers as closely as possible.

Benefit to Fedora

Having graphical applications available as Flatpaks has a number of benefits:

• It allows graphical applications to be maintained in a modular fashion, with dependency chosen and tested by the application maintainer. It is the delivery vehicle for Fedora modularity for graphical applications.
• It allows new versions of applications to be tested and used without having to update packages on the system
• It allows users to upgrade applications without rebooting
• It helps on ostree-based systems like "Atomic Workstation" where installing RPMs is tricky. (They can be layered, but the user experience will not be smooth.)

Scope

• Proposal owners: (f27)
  • Create and maintain a flatpak-runtime module
  • Provide tools for application authors to use to create module descriptions for their flatpaks
  • Provide patches for the container build pipeline (atomic reactor and friends) to build flatpaks as well as containers
  • Create some way to get summary information for all flatpaks on registry.fedoraproject.org; this might be a patch to the codebase, a look-aside file, or a separate service.
  • Modify flatpak and gnome-software so that flatpaks can be installed from registry.fedoraproject.org.

• Proposal owners: (f28)
  • Provide a "SDK" profile of the flatpak-runtime module to create a Flatpak SDK for third-party non-RPM builds against the SDK using flatpak-builder

• Other developers: (f27)
  • Provide exports of built modules as repositories (the "On Demand Compose Service")
  • Provide some reasonably self-service way for packagers to create modules without a lot of overhead. (Does it make sense to allow application modules where when a package corresponds one-to-one to a module to allow the modulemd to live in dist-git next to the spec file?)
  • Allow Fedora packagers to submit module builds
  • Allow uploading OCI images to registry.fedoraproject.org Upstream pull request

• TBD: updates / bodhi
  • What happens when an update is filed for a package that is bundled in an application or runtime? Is a "testing" rebuild of the Flatpak done at that point? (Is one built on commits to dist-git?)
  • Is it possible file an update for an application rather than for a package?
  • How do users download testing versions of flatpaks?
  • What happens when multiple updates overlap (package A and B are bundled in the application and have updates updates-testing, package A is pushed to stable)? Is a new version of the package built that contains only updates that have been pushed to stable?

• Release engineering: #Releng issue number (a check of an impact with Release Engeneering is needed)

• • List of deliverables: Most likely, runtime and applications would not be part of the deliverables list. However, we will need to consider the quality of the runtime and applications as part of the overall quality of release - if some common application did not run on upgrade that would seriously affect users. This should, as much as possible, be addressed through continuous automated testing.

• Policies and guidelines: The people working on this change will need to work closely in the development of module guidelines, and make sure that Flatpak specifics are documented as well (for example, documenting the creation of a 'flatpak.json' with permissions and other metadata for the Flatpak). It's possible some changes will be needed to the packaging guidelines to make sure that all relevant packages relocate to /app properly, but it's expected that most packages that follow the current packaging guidelines will work correctly.

• Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

The upgrade question here mostly is what happens when a user already has an application installed from RPM if the package maintainer decides that they want to use flatpaks as the main or only delivery vehicle for the application. GNOME Software probably would need specific code to detect this case and install the Flatpak as an "upgrade" overriding the old RPM installed on the system (or potentially removing it.) The recommendation for F27 will be to continue packaging a traditional RPM in addition to any Flatpak, so any work here isn't needed until F28.

User Experience

If an application a user want to install is available as a flatpak on registry.fedoraproject.org, it will be transparently be installed rather than installing the RPM. (Assuming that we have some basic security update plan in place - if not, then we should prefer RPM installs) Applications that support running sandboxed will run sandboxed, providing additional security to the user. Updates to Flatpak applications and runtimes will be offered and take place without a system reboot.

Dependencies

This change is strongly intertwined with both modularity and containerization efforts. We plan to provide the bulk of the development resource for any Flatpak-specific changes needed to infrastructure and to the extent we can, and it is necesary, provide help for other features we depend on.

Contingency Plan

• Contingency mechanism: If the basic plan is working, but support for building Flatpaks or support for distributing them via registry.fedoraproject.org is not available in time for F27, we simply will not announce the feature and not enable registry.fedoraproject.org in GNOME Software.
  • If modifying atomic-reactor to build Flatpaks turns out to be infeasible, we could provide a separate Koji plugin and/or content generator.
  • If distributing Flatpaks via registry.fedoraproject.org turns out to be infeasible, we could distribute via ostree repository; this would likely put the F27 timeline in jeopardy because more new infrastructure components would be needed.
• Contingency deadline: If a fully working pipeline enabling packagers to create a Flatpak, build it, and have it appear on registry.fedoraproject.org isn't available by the Beta Freeze (2017-09-05), then this likely should not be advertised for F27.
• Blocks release? No
• Blocks product? No