#717 easy way to access RPM provides of a module build
Closed: Invalid 6 years ago Opened 6 years ago by ttomecek.

I think it's obvious that we need an easy way to know RPM provides of modules and ideally have it in a dedicated service so everyone can query it easily.

I talked to @zvetlik about this today and we figured out how it could be done: once MBS builds a module, it submits all RPM provides to PDC. The problems is, that may be a lot of data. Is that actually a problem?

The next step could be to write a dnf plugin, which would utilize the data (dnf module-repoquery?).

Is anyone working on something like this already?


There should be an existing script for this in the releng repo. Please see:
https://pagure.io/releng/blob/master/f/scripts/branching/modulepkg.py

Bu it takes quite an amount of time to parse the modulemd-s within PDC. It would be nice having this information extracted into a separate PDC's table/API but it's out of scope of this issue.

I also agree that having a dnf plugin would be a nice thing.

Bu it takes quite an amount of time to parse the modulemd-s within PDC. It would be nice having this information extracted into a separate PDC's table/API but it's out of scope of this issue.

This is exactly what I mean. We need a simple solution with good user experience (getting results in seconds, not minutes)

Who and when generates RPM repository? PDC is completely useless in this case and dnf will not even try to contact it.

@ignatenkobrain how about if MBS got a list of provides from a module build and put it to PDC. Would dnf be capable of utilizing such data in order to resolve dependencies?

I would strongly suggest not having DNF query PDC. PDC was not designed with that use case in mind at all and there's all kinds of issues you'd cause by doing it.

@ttomecek I totally support @sochotni. Because:

  • It is yet another data format
  • It is slow and not designed for this

Does it mean that best solution to this problem is to create a new, dedicated service?

Using Koji is not an option? You should be able to extract that info in a few API calls.

@ttomecek why do you need new service? we just need compose to query it and what's ODCS is supposed to do.

Okay, let's get back to square 1. Imagine, that I am doing a new module. I need to figure out in which modules build and runtime dependencies are present of all components of the new module (and which are missing and need to be modularized). How do I do that (as easy as possible, ideally doing a single command or doing a single query on web)?

Does this need to be a service query at all? For regular RPMs, everything DNF needs is in the static repo metadata.

Shouldn't we be aiming for the same situation for modules? (i.e. the repo metadata not only tells DNF which modules exist and what streams they contain, but also which RPM dependencies each stream satisfies).

@ncoghlan, it already does. modulemd contains list of RPM artifacts. basically dnf takes them and can tell which provides each modules has.

@ignatenkobrain If dnf's reading all the individual modulemd files to do that, it sounds less like the repo-level RPM metadata generated by createrepo, and more like having to poke around inside individual RPMs.

Either way though, this is probably the wrong issue tracker for the discussion.

I'd suggest we take it back to the main modularity tracker, document how DNF itself currently handles the problem, and then ask how we'd like to expose that capability to other tools and services.

@ncoghlan, in repomd there is only one modulemd which is multi-document yaml. And the way modularity metadata is designed it is poking around inside individual RPMs after all ;)

Either way though, this is probably the wrong issue tracker for the discussion.

Agree! It should not be part of MBS at all.

Metadata Update from @ignatenkobrain:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

6 years ago

Metadata Update from @ncoghlan:
- Issue status updated to: Open (was: Closed)

6 years ago

Metadata Update from @ncoghlan:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

6 years ago

(Oops, looks like Pagure is affected by the old "Submitting a commit from a page you opened a while ago may revert metadata changes" problem)

Login to comment on this ticket.

Metadata