[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Flatpaks in src.fedproject.org - a namespace conumdrum
From: Owen Taylor <otaylor () redhat ! com>
Date: 2018-09-04 20:00:25
Message-ID: CAEJK_djYH7fZ6E7kFaVs-78Rqk_mrBd4OsihRumfiTBnpgq0kw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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]
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>The current \
idea</div><div>=============<br></div><div><br></div><div>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.) <br></div><div><br></div><div>Because Flatpaks are a module, they share \
the modules/ namespace on <a \
href="http://src.fedoraproject.org">src.fedoraproject.org</a> with other \
modules.<br></div><div><br></div><div>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. <br></div><div><br></div><div>The \
problem</div><div>==========</div><div>Each flatpak needs to be tagged into two koji \
tags:</div><div><br></div><div> f29-modular-updates (this is the destination for \
the module build)<br></div><div> f29-flatpak (this is the destination for the \
Flatpak container build)<br></div><div><br></div>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 <a \
href="http://src.fedoraproject.org">src.fedoraproject.org</a> are just modules and \
what modules are also Flatpaks, so it has no way to populate the f29-flatpak tag \
package list correctly.<br></div><div dir="ltr"><br></div><div dir="ltr">(*) <a \
href="https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodhi2/back \
end/templates/owner-sync-pagure.j2">https://infrastructure.fedoraproject.org/cgit/ansi \
ble.git/tree/roles/bodhi2/backend/templates/owner-sync-pagure.j2</a><br></div><div \
dir="ltr"><br></div><div dir="ltr"><div>Solution 1 - separate \
namespace<br></div><div>==========================</div><div>We could put flatpaks \
into their own namespace in <a \
href="http://src.fedoraproject.org">src.fedoraproject.org</a>. 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.<br></div><div><br></div><div>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. <br></div><div>Downsides: obscures the \
relationship between Flatpaks and other modules. \
<br></div><div><br></div><div>Solution 2 - project \
tags</div><div>===================</div><div>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'.</div><div><br></div><div>Upsides: \
have to change nothing but owner-sync-koji and the fedpkg request-repo/fedscm_admin \
code path.</div><div>Downsides: obscure. project tags are modifiable by the owner - \
so things could get out of sync.<br></div><div><br></div><div>Solution 3 - look at \
module contents</div><div>============================</div><div>If a branch under <a \
href="http://src.fedoraproject.org/modules">src.fedoraproject.org/modules</a> 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.<br></div><div><br></div><div>Upsides: nothing else to worry about beyond what \
has to be set up for building Flatpaks.<br></div><div>Downsides: per-branch - not \
per-repository, would be wrong on initial repository creation, which is when \
owner-sync-koji is run.<br></div><div><br></div><div>Solution 4 - \
????</div><div>=============</div><div>[ your proposal goes \
here]<br></div></div></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic