Dne 03. 11. 20 v 13:14 Petr Pisar napsal(a):
On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote:
Daniel Mach <dmach@xxxxxxxxxx> writes:
The API is clear: DNF expects additional 'modulemd-obsoletes' YAML
documents in modules.yaml. The new document format is getting into
libmodulemd and there's going to be documentation on how to write it.
Then there's a question how to get the documents into modules.yaml. From
my perspective, it's up to Fedora infra/releng/packaging people. Whether
it should be in dist-git, git repo (similar to modulemd-defaults or
comps), PDC, Bodhi (similar to updateinfo) or somewhere else - that's
entirely their call.
I think the package/module maintainer should be able to set the EOL and
obsoletes for their module in a simple fashion, preferably without
requiring to create tickets for releng or anyone else. So that leaves
dist-git as the only option, right?
I also like the idea of having EOL data in dist-git in hands of the packagers.
The problem is that a compose process run by relengs does not use dist-git at
all. It picks up builds from Koji and data from various git repositories. The
various git repositores is where the module default profiles live. Problem is
that the various repositories are not dist-git. They have a rigid commit
access by a few people. Those are not packagers.
We could create a dedicated repository in dist-git for collecting the EOL data
from various module maintainers and give the module maintainers a commit
access there. But the problem with dist-git is that a special repository does
not fit into the namespace schemata (rpms, modules, tests).
We could create a dedicated repository on pagure.io instead, give maintainers
a commit access there (the account system is shared with Fedora, I think) and
confugure pungi (a tool run by relengs to make composes) to read EOL data from
there. But there still had to be a manual step of granting the commit access.
Another option would be adding the EOL data into modules dist-git
repositories. To the same branches where modules are built from. But
a different file. Pungi would enumarate all module builds directed to
a compose, locate their dist-git sources by mapping name:stream to
git://src.fedoraproject/org/modules/name.git#stream and download EOL data from
there. That would enable module maintains to control EOLs simply by pushing an
eol.yaml file into the branch of the module.
Wouldn't relengs object that it's not accountable because the EOL data can be
updated asynchrously of module builds and tagging in Koji? And isn't that what
we want to acheive -- EOL data independent from the module builds?
Alternatively we could append EOL YAML document to modulemd YAML document in
the dist-git (a YAML file can contain multiple YAML documents) and rebuild the
build. That way the EOL data would get together with the modulmd to Koji
and to the compose. But that would bind the EOL data to module builds. If we
wanted to EOL a module stream, we would have to make an unnecessary module
build. Would it be still worthwile?
-- Petr
Thanks for your write-up, it perfectly describes the workflow issues and
challenges.
The mapping from dist-git to compose or bodhi update is not entirely
straightforward. It starts when a package is built and tagged in a tag
associated with a release. That makes me think that extending this to
modulemd-obsoletes could also work, but that would require "building" (a
simple import from dist-git to the build system might be sufficient) and
tagging them in the build system. That would allow tagging the
modulemd-obsoletes for a compose or attaching them to a bodhi update.
There's only one if - if someone could extend the infra tools to support
this new content...
The non-dist-git git repos with limited access are a workaround for lack
of tagging support - you simply export the repo content and include it
where you need without tagging / cherry-picking / organizing content in
the build system.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
