DevHeads.net

Proposal: Add a separate “flatpaks/” namespace.

Currently, the content for a Flatpak in Fedora can be found in
modules/<application>. E.g.:
<a href="https://src.fedoraproject.org/modules/quadrapassel/tree/master" title="https://src.fedoraproject.org/modules/quadrapassel/tree/master">https://src.fedoraproject.org/modules/quadrapassel/tree/master</a> - I’d
like to propose creating a separate namespace in src.fedoraproject.org
- flatpaks/

Benefits:
* Allow automation to easily distinguish Flatpaks from other modules.
(<a href="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/thread/ANZRNH75N7MHRO6VEUNT4WOMHO5PNXGW/" title="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/thread/ANZRNH75N7MHRO6VEUNT4WOMHO5PNXGW/">https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject....</a>
)
* Make it easy to browse through the source of available Flatpaks
* Reduce some confusion. A Flatpak is a module, but it’s *also* a
container, and the dist-git repository will include files for both.

Downsides:
* We have a few graphical applications that are available as standard
loose-rpm macros (gimp, rawtherapee, skychart). While it should work
to have flatpaks/gimp and modules/gimp build different streams of the
gimp module, it’s going to be more confusing than different branches
in the same repository. (There are even possibilities for using the
*same* branch using module-stream-expansion, though that’s not
something I’d encourage at the moment.)

Needed steps:
* Remove special casing of flatpak => modules in Bodhi
<a href="https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/models.py#L1061" title="https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/models.py#L1061">https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/models.p...</a>
* Adjust namespace special-casing in fedpkg
<a href="https://pagure.io/fedpkg/blob/master/f/fedpkg/cli.py" title="https://pagure.io/fedpkg/blob/master/f/fedpkg/cli.py">https://pagure.io/fedpkg/blob/master/f/fedpkg/cli.py</a>
* Adjust namespace special-casing in fedscm_admin
<a href="https://pagure.io/fedscm-admin/blob/master/f/fedscm_admin/utils.py" title="https://pagure.io/fedscm-admin/blob/master/f/fedscm_admin/utils.py">https://pagure.io/fedscm-admin/blob/master/f/fedscm_admin/utils.py</a>
* In fedscm_admin: Map flatpaks namespace to the ‘module’ PDC branch
type when storing the SLA into the PDC, to avoid PDC changes, and
because the SLA really is a module SLA.
* Adjust distgit pagure configuration to add flatpaks to
ALLOWED_PREFIX and REQUIRED_GROUPS
<a href="https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/distgit/pagure/templates/pagure.cfg" title="https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/distgit/pagure/templates/pagure.cfg">https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/dis...</a>
* Add flatpaks/ to the kojid allowed_scms configuration
<a href="https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koji_builder/templates/kojid.conf" title="https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koji_builder/templates/kojid.conf">https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koj...</a>
* Add flatpaks/ to the module-build-service SCMS configuration
<a href="https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/mbs/common/templates/config.py" title="https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/mbs/common/templates/config.py">https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/mbs...</a>
* Adjust the owner-sync-pagure script to handle flatpaks/
<a href="https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodhi2/backend/templates/owner-sync-pagure.j2" title="https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodhi2/backend/templates/owner-sync-pagure.j2">https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bod...</a>
* Move or reimport existing Flatpak repositories
(modules/eog, modules/feedreader, modules/flatpak-common,
modules/flatpak-runtime,
modules/gnome-clocks, modules/gnome-tetravex, modules/quadrapassel)

Potential issues:
* We should probably move flatpak-common to the flatpaks/ namespace
for ease of discovery, but it isn’t in any way a flatpak, it’s just a
module that Flatpaks can depend on.
* The ability of modules to include other modules won’t work without
further adjustments to the MBS config.py (MODULES_ALLOW_REPOSITORY) -
I don't see this as useful functionality for Flatpaks.

Comments

Re: Proposal: Add a separate “flatpaks/” namespace.

By Owen Taylor at 01/11/2019 - 10:42

On Tue, Jan 8, 2019 at 12:28 PM Owen Taylor < ... at redhat dot com> wrote:
Digging into this, I don't think this is right - it would break the
1:1 mapping between pagure branches and "component branches" in PDC
that we currently have and the scripts count on. I think the right
thing is:

* Modify the ReleaseComponentType table in the PDC database to add 'flatpak'

[ Or could be done by adding a migration to the PDC codebase, adding
the redeploying, but considering that we're working on replacing the
PDC, doesn't seem worthwhile.]

Owen

Re: Proposal: Add a separate “flatpaks/” namespace.

By John Harris at 01/10/2019 - 18:15

+1, it would be nice to separate flatpaks from the actual distribution.

Re: Proposal: Add a separate “flatpaks/” namespace.

By Kevin Fenzi at 01/10/2019 - 17:29

+1 from me. That seems like a nice reasonable thing for us to do. :)

kevin

Re: Proposal: Add a separate “flatpaks/” namespace.

By Matthew Miller at 01/08/2019 - 15:05

On Tue, Jan 08, 2019 at 12:28:51PM -0500, Owen Taylor wrote:
I'm +1 to this for this reason. I think it's less confusing than the
downside loose-module confusion. :)

In related news, I'm killing the rawtherapee "loose-rpm" module and just
making a flatpak one.

Question: would this open up the possiblity of offering different _flatpak_
streams? I'd like to have a stream where the rc releases are built so people
who want to try those can.

I'd suggest just making a flatpak-common repo in flatpaks/ with a README
linking to the module namespace.