= System Wide Change: Graphical Applications as Flatpaks = https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks Change owner(s): * Owen Taylor <otaylor@xxxxxxxxxx> This change is to enable package maintainers to build Flatpaks of their applications and make those Flatpaks available for installation. == Detailed Description == See Workstation/Flatpaks [1] for the full development plan. The goal of this change is make Flatpaks available as a distribution mechanism for software packaged in Fedora. Multiple Flatpaks on the system can share a runtime of common libraries. There will be a single Fedora runtime maintained on the same schedule as the Platform module for Fedora. It will be be defined as a module that includes libraries that are commonly used for graphical applications. Some of these will inherit from the Platform module. Applications then bundle the code for the application itself and for additional libraries they depend on beyond the base runtime. Each application has its own module in which the relevant RPMs are rebuilt with a special RPM macros (in the flatpak-rpm-macros package) to relocate the application and bundled libraries into the /app prefix. (This is necessary, because inside an executing Flatpak, the application is mounted at /app, and the runtime at /usr) The packages are then composed into Flatpaks by the layered image service, sharing as much of the workflow and code as possible with containers. While the native delivery mechanism for Flatpaks is as an ostree repository, they can also be distributed as OCI images, and our goal is to use this format during the build process, and to distribute them to users via registry.fedoraproject.com. Automation of rebuilds and integration with Bodhi will also be needed to make sure that security and bug-fix updates to packages end up being distributed to users. This part is least specified at the current time, and full automation may not be achievable for Fedora 27. If the above plan is followed, most of this work is shared with work needed for modularity in general and for server-side containers. == 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 [2] ** Make sure that Bodhi updates can be submitted for Flatpaks/OCI Images in the same way as for Docker containers (no significant code changes are expected beyond the current work to enable multiple types of Bodhi updates.) * Other developers: (f28) ** Create a unified workflow for package and container/flatpak updates (detailed plan to be developed, something like:) *** updates submitted to bodhi for a package should trigger automatic module and container/flatpak builds *** Pushing a package to stable should push the updated flatpaks/containers *** the Bodhi user interface should show modules/containers that include a package and their status * Release engineering: [3] (a check of an impact with Release Engineering 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) [1] https://fedoraproject.org/wiki/Workstation/Flatpaks [2] https://github.com/docker/distribution/pull/2076 [3] https://pagure.io/releng/issue/6876 Thanks, Jaroslav _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
