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/bodhi2/backend/templates/owner-sync-pagure.j2 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]
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
