[ Broadening the audience to include devel(a)lists.fedoraproject.org ]
Anybody have thoughts about my question below? some examples of places
which will need logic like this to replace PDC usage:
Resolve a module name:stream to a particular build, and do dependency
Get the flatpak-runtime modulemd to find what packages aren't in the
runtime and need to be bundled
Load the modulemd for particular module builds to get profile
information and figure out what to install in a container
Load modulemd and do dependency expansion to build a container locally
Load the modulemd module we are building into a flatpak to find what
runtime it is using, and hence the right build target
On Mon, May 21, 2018 at 1:29 PM, Owen Taylor <otaylor(a)redhat.com> wrote:
My understanding is that with the planned retirement of the PDC:
Querying for module information should be done using the MBS and/or Koji
Various code that I maintain (in OSBS, fedmod, and random tooling) wants
to do module build lookups - different variations of "look up the modulemd
for latest build of a NAME:STREAM[:VERSION]". Variations generally being
exactly what "latest" means here.
The code generally already is using Koji and the MBS api is quite limited,
so I've chosen to do the lookups via Koji.
Is a test tool that incorporates most of the capability that I needed
across my uses. It's distinctly more than a couple of lines of code - I can
cut-and-paste it for now, but what's the right long-term home? Is there a
My best idea right now is that if the 'base_version' and'status' part of
my code was simplified to simply be "tag" and avoid reliance on the tag
structure of Fedora, then this might make a reasonable addition to the Koji
CLI and API - there are some things that using raw tags for the query makes
trickier, but it's probably workable.
Thanks for any input!