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 'gedit.json'. * 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 branches. * 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. Todo list ========= 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 images around. 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 git repository. 4) Review how close we are to being able to point GNOME Software at an OCI container registry to find flatpaks. _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
