Filtering by "provides" does not match anything, when run on a Debian machine

[ydirson]

With the test script below, which tries to find out which packages provide a given relationship expression, when run on AlmaLinux 10 it works as expected:

$ python3 resolve-provides.py
bash: ['bash-5.2.26-6.el10.x86_64_v2']
/bin/sh: ['bash-5.2.26-6.el10.x86_64_v2']
libgcc_s.so.1(GCC_3.3.1)(64bit): ['libgcc-14.2.1-7.el10.alma.1.x86_64_v2']
glibc >= 2.36: ['glibc-2.39-37.el10.alma.1.x86_64_v2', 'glibc-2.39-43.el10_0.alma.1.x86_64_v2', 'glibc-2.39-46.el10_0.4.alma.1.x86_64_v2', 'glibc-2.39-46.el10_0.alma.1.x86_64_v2']

OTOH when running on Debian13 (0.74 + patches including backport from master to set disttype properly) or Debian unstable (0.75 plus patches):

$ python3 scripts/resolve-provides.py
bash: []
/bin/sh: []
libgcc_s.so.1(GCC_3.3.1)(64bit): []
glibc >= 2.36: []

What can be the problem?

#!/usr/bin/env python3

import tempfile
import dnf

with (tempfile.TemporaryDirectory() as persistdir,
      tempfile.TemporaryDirectory() as reposdir,
      tempfile.TemporaryDirectory() as cachedir,
      tempfile.TemporaryDirectory() as varsdir):
    # avoid any system configuration
    conf = dnf.conf.Conf()

    conf_config_file_path = conf._config.config_file_path()
    conf_config_file_path.set(value='/dev/null', priority=conf_config_file_path.getPriority())
    conf_reposdir = conf._config.reposdir()
    conf_reposdir.set(conf_reposdir.getPriority(), reposdir)
    conf_persistdir = conf._config.persistdir()
    conf_persistdir.set(conf_persistdir.getPriority(), persistdir)
    conf_system_cachedir = conf._config.system_cachedir()
    conf_system_cachedir.set(conf_system_cachedir.getPriority(), cachedir)
    conf_varsdir = conf._config.varsdir()
    conf_varsdir.set(conf_varsdir.getPriority(), varsdir)

    # necessary to solve deps against concrete files
    conf._config.optional_metadata_types().getValue().push_back('load_filelists')

    db = dnf.Base(conf=conf)
    db.repos.add_new_repo("BaseOS", conf, [f"https://vault.almalinux.org/10.0/BaseOS/x86_64_v2/os/"])
    db.fill_sack(load_system_repo=False)

    for rel in [ 'bash', '/bin/sh', 'libgcc_s.so.1(GCC_3.3.1)(64bit)', 'glibc >= 2.36' ]:
        providers = db.sack.query().filter(provides=rel)

        print(f"{rel}: {[str(p) for p in providers]}")

[m-blaha]

I think this can be caused by architecture mismatch. The sack is created with detected architecture (basically from uname -m, most likely x86_64). But repository contains only packages with x86_64_v2 and noarch architectures. If I set conf.substitutions['arch'] = 'x86_64_v2' before creating Base instance, the example works.
Is it possible that your AlmaLinux machine is x86_64_v2?

[ydirson]

I think this can be caused by architecture mismatch. The sack is created with detected architecture (basically from uname -m, most likely x86_64). But repository contains only packages with x86_64_v2 and noarch architectures. If I set conf.substitutions['arch'] = 'x86_64_v2' before creating Base instance, the example works. Is it possible that your AlmaLinux machine is x86_64_v2?

Yes that's the case, and it indeed works for me too, thanks!

But why is it that .filter(provides=rel) also filters on arch, while this was not requested? The base query does not, and other filters like .available() don't have this effect.

[m-blaha]

I agree that dnf handles this inconsistently. Behavior varies across different filters and is not documented.

The provides filter does not work with foreign architecture packages due to its implementation: it uses the whatprovides index in libsolv. Libsolv skips packages with incompatible architectures when creating this index.

The name filter, however, iterates through all solvables and compares the name attribute with the pattern, with no foreign architecture filtering in place.