One of main questions that we need to settle before implementing building Flatpaks in Koji
is whether there is a module-per-Flatpak or not. At the working group meeting last Monday
I was leaning towards "no", to keep things simpler for contributors. I had a
long conversation with Langdon and Matthias about the current state of Modularity and
flatpaks and that changed my mind to lean towards "yes"
One reason is that if we don't create a module-per-flatpak, we need to write a
"flatpak build service" that looks something like the Module Build Service and
get that deployed in Fedora infrastructure. This is a lot higher overhead than whatever
tweaks we would need for the Module Build Service.
But just as importantly, if the goal of the Fedora project is to start taking packages off
the F2<x> release train, spending effort on something that only makes sense in the
context of that release train doesn't make a lot of sense.
That is, currently, the LCMS color management library has a f26 branch that points to
lcms-1.19. GIMP in F26 will use the LCMS in F26. But the goal of Modularity is that there
will instead by a 1.19 branch of lcms. For a core library like nss, we can say that the
"f27 version of nss is 3.29" because the base-runtime or generational-core
modulemd file will list the branch. But there is no obvious way of saying what version of
LCMS is "part of" F27.
With a no-module approach to flatpaks - saying that "BuildRequires: lcms2" in
the GIMP Spec file is sufficient and our tooling figures out everything from there -
we'd have to "reinvent the F27 branch" by having a mega-module listing
branches of everything that is used by every application. It's probably better to
simply start with the GIMP module that lists the branch of lcms that it needs.
There are definitely serious work items that we will need to make building Flatpaks as
modules not a nightmare for package maintainers, but these are at least partially the
*same* work items as needed for other module maintainers, and often things that that
Modularity WG already are planning for.
* There needs to be autobuilding on changes to constituent packages
* There needs to be bodhi integration
* There needs to be an easy way to create a Flatpak module and build definition. You
could imagine that if rpms/gedit exists, running 'fedpkg flatpak-init gedit'
creates modules/gedit with a template metadata.yaml, and flatpak/gedit with a template
* There needs to be a generation process for modulemd file, where the very detailed list
of included rpms is generated from something higher level as part of the build process.
* There needs to be tooling to help module maintainers deal with updating their
* There needs to be standards around branch lifetimes so that the GIMP maintainer
doesn't get blindsided when the LCMS maintainer decides they no longer want to support
the 1.19 branch.
1) Figure out how we can get the RPM macros for /app into the buildroot for a module. It
may be possible to use the 'buildrequires:' tag to pull in a flatpak-build module
that has the necessary macros.
2) Settle on an approach for building Flatpaks out of packages. Direct code in a koji
plugin is simplest, but putting it into OSBS/Atomic Reactor would have the advantage of
more closely following the container path, allowing reuse of the logic for pushing OCI
3) Figure out where Flatpak metadata lives in dist-git. Container build instructions will
live in docker/ and be *referenced* by the modules in modules/. Putting flatpak metadata
into docker/ seems bizarre, so a separate dist-git namespace is the obvious approach. A
different approach would be to put it alongside the SPEC file or modulemd file in the same
4) Review how close we are to being able to point GNOME Software at an OCI container
registry to find flatpaks.