Flatpaks in src.fedproject.org - a namespace conumdrum

[Owen Taylor]

The current idea
=============

A Flatpak is a module. The way that the module is deployed is by creating a
Flatpak container from the module. (Other modules might be deployed by
installing by RPMs directly or creating a server container.)

Because Flatpaks are a module, they share the modules/ namespace on
src.fedoraproject.org with other modules.

Flatpaks are also containers - but to keep things simpler, we don't require
a separate git project in the container/ namespace - the container.yaml is
kept in the same git project and OSBS builds the Flatpak container directly
from there.

The problem
==========
Each flatpak needs to be tagged into two koji tags:

  f29-modular-updates (this is the destination for the module build)
  f29-flatpak (this is the destination for the Flatpak container build)

The package list for each koji tag is populated from pagure by the
owner-sync-pagure script (*). But that script has no way of knowing what
repositories under modules/ in src.fedoraproject.org are just modules and
what modules are also Flatpaks, so it has no way to populate the
f29-flatpak tag package list correctly.

(*)
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodh...

Solution 1 - separate namespace
==========================
We could put flatpaks into their own namespace in src.fedoraproject.org.
The MBS configuration would have to be changed to also allow building
modules from the flatpaks/ namespace, the Bodhi code that just landed would
need to change, and there are doubtless other places where we'd need to
change things to extend the list of namespaces, but it would mostly be
straightforward.

Upsides: would make the handling of flatpaks in the infrastructure code a
bit more regular, and also make it easy to see a list of all Flatpaks.
Downsides: obscures the relationship between Flatpaks and other modules.

Solution 2 - project tags
===================
The owner-sync-koji code could be adapted so that to find the set of
packages for f29-flatpak it looks for projects in modules/ with a project
tag of 'flatpak'.

Upsides: have to change nothing but owner-sync-koji and the fedpkg
request-repo/fedscm_admin code path.
Downsides: obscure. project tags are modifiable by the owner - so things
could get out of sync.

Solution 3 - look at module contents
============================
If a branch under src.fedoraproject.org/modules has a container.yaml file
with a flatpak: key at the toplevel, then we know it's a flatpak module.
owner-sync-koji could potentially just check this.

Upsides: nothing else to worry about beyond what has to be set up for
building Flatpaks.
Downsides: per-branch - not per-repository, would be wrong on initial
repository creation, which is when owner-sync-koji is run.

Solution 4 - ????
=============
[ your proposal goes here]