The capabilities name is neither generic enough, nor is it correct in the dnf context. For dnf context, provides could be a better fit for what this is.

changed to provides.
context: for choosing capability. We already have a provider.

Why the em-dash. Personally, if one uses em-dash, it feels like they did not consider the wording at all.

Again, too technical. The whose stdout is not relevant and too literal. See the other docstrings

See the raises just below here. Be consistent.

Incorrect quotations of the return type

• The package is not installed when you need to call this
• Multiple packages can provide the same provides, particularly if the user did not add relevant constraints

This is just wrong isn't it? Can't figure out what you are trying to catch here.

Move this at the top and you can avoid the intermediate caps. I commented about this very recently didn't I?

No contextlib.suppress. There is a special case being handled, then document it properly

Sorry - just seeing this now, but prolly made a duplicate comment: #4804 (comment)

Not a good approach, see the other comments. The repoquery might give you more flexibility on the format and allow you to get more information to process further like the repoid.

We now , run repoquery for each of the packages in a script. Which is actually easier to parse. Addressed in 0fb9b50.

Try running dnf repoquery --whatprovides=make,cmake and see what you get

@LecrisUT , When multiple arguments are passed to --whatprovides, unresolved items are silently ignored and there isn’t a flag to make the command fail or report them explicitly. It also returns a merged result set without preserving input-to-output mapping.

➜  tmt git:(vaibhav-discover-only-providers-whatprovides) ✗ dnf repoquery --whatprovides=make,cmake,pikachu
Updating and loading repositories:
Repositories loaded.
cmake-0:3.31.11-1.fc42.aarch64
cmake-0:3.31.6-2.fc42.aarch64
make-1:4.4.1-10.fc42.aarch64

Is there something clever we could do at this point?

Check the queryformat and what it can do. fedrq does some complex handling also if you need more reference

@LecrisUT 🥇 ,
I looked into queryformat and fedrq, but doing a bulk dnf repoquery creates a couple of blockers since we're just executing a shell script on the guest.
My findings,

• Lost order: DNF merges and sorts the final list, which completely destroys the 1:1 input-to-output mapping we need to track things.
• Silently missing packages: If DNF can't resolve an item, it just drops it from the output without throwing an error. We're left with no way to know which specific capability failed.

• Lost order: DNF merges and sorts the final list, which completely destroys the 1:1 input-to-output mapping we need to track things.

Note that there is never a 1:1 mapping, e.g. look at the output of --whatprovides cmake there having multiple items that provide it, and that is expected and we have to work around them. What should be done, I don't know.

A concrete example case are the copr_repo provider.

• Silently missing packages: If DNF can't resolve an item, it just drops it from the output without throwing an error. We're left with no way to know which specific capability failed.

Yes certainly, that's why I mentioned looking in the queryformat tags. fedrq does provided the structured information when you do the multi-query, but I don't know how it does it if it's from the tags that repoquery provides or not. I will try to look on my end as well to see what I can gather

Provides should return a set. did some refactoring in ad05ffb.

This supresses parsing errors (and others too) - ambigous. Suggest adding a debug() log here:

for cap, line in zip(caps, (stdout or '').splitlines()):
    try:
        result[cap] = RpmVersion.from_nevra(line.strip())
    except ValueError:
        self.debug(f"Could not resolve capability '{cap}': {line.strip()}")

thanks for the suggestion, addressed in f68411a.

Should be decorated as abstractmethod.

What is the reason for different type of provides here and in the engine?

Empty mapping is not mentioned as a possible return value. You could use defaultdict instead of dict so that all keys would be mapped to None by default.

Addressed in cdc2b24.

Related to the note about defaultdict above, dependency_to_version as an empty mapping does not match what resolve_provides() says it would return. verify can also be defaultdict, it would be easier to understand than setdefault() below.

Addressed in cdc2b24.

%{epoch} can potentially output the literal string (none) under rpm -q for packages without an explicit epoch - no? I cannot remember correctly - in some provider while testing, if an epoch doesnt exist, none is returned @LecrisUT correct me please if Im wrong.

@AthreyVinay thankyou.

%{epoch} outputs the literal string (none) for packages without
an explicit epoch (the majority of packages). With the old queryformat,
from_nevra silently parsed (none) as part of the version field — so bash would
appear to have version (none):5.2.37 instead of 5.2.37

qf -> spills out (none). Fixed in 7e978fc.

%{epoch} is 0 if unset, confirmed it:

$ dnf repoquery --queryformat="%{epoch}\n" tmt
Updating and loading repositories:
Repositories loaded.
0

rpm -q vs dnf repoquery are completely different things. Which one should we use 🤷. rpm -q has more tags, but they provide less info

%{epoch} is 0 if unset, confirmed it:

Thanks @LecrisUT , however, rpm -q is used here which outputs (none)

Actually rpm -q is the wrong tool to use:

$ rpm -q --whatprovides fish --queryformat="%{nevra}\n" 
no package provides fish
$ dnf repoquery --whatprovides=fish --queryformat="%{full_nevra}\n" 
Updating and loading repositories:
Repositories loaded.
fish-0:4.0.2-5.fc43.x86_64
fish-0:4.2.0-2.fc43.x86_64

It only queries what is already installed, but at this point we want to query what is available

No arguing that 👍

There are two scenarios to consider:

1. Before the RPM is installed

• rpm -q does not work at this stage.
• Only dnf repoquery can be used.
• Note: For repoquery to work, repositories such as tmt-artifact-shared (and any other required repos) must already be configured. Which is the case and hence we can go with repoquery.

2. After the RPM is installed

• Both rpm -q and dnf repoquery work as expected.

• Note: For repoquery to work, repositories such as tmt-artifact-shared (and any other required repos) must already be configured. Which is the case and hence we can go with repoquery.

Not really, we can point it to a repo with no /etc/yum/repos.d. The design would have to be changed to link this to repository to know which one to use if this is needed. I don't think it would be needed for now.

2. After the RPM is installed

But that is too late:

• If the package was not installed, then this is in a weird state
• The original issue is to resolve the requires/recommends that could use non-package names. This can either be used for constructing the verify step in the artifacts step or when handling the special case of downloaded rpm artifacts and re-installing pre-installed packages
• This could be used to allow users to use the arbitrary package names in a custom prepare/verify phase, but should we be giving them that much flexibility in the first place?

The head -1 is incorrect here. It is perfectly fine for multiple packages to provide the same provide.

You are replicating %{full_nevra} here

Do you have a reason for hiding stderr?

When I use repoquery

➜  ~ dnf repoquery --whatprovides=cmake --queryformat="%{full_nevra}\n"
Updating and loading repositories:
Repositories loaded.
cmake-0:3.31.11-1.fc42.aarch64
cmake-0:3.31.6-2.fc42.aarch64
➜  ~ dnf repoquery --whatprovides=cmake --queryformat="%{full_nevra}\n"  2>/dev/null
cmake-0:3.31.11-1.fc42.aarch64
cmake-0:3.31.6-2.fc42.aarch64

But the stdout and stderr are already separated when you run the script with tmt, see CommandOutput