Bug 2035577

I was able to trace this behaviour back to enabled system modules. If the system has modules enabled, these packages are also ignored for remote repos. Even when "load_system_repo=False" is set.

Workaround:
add repo.module_hotfixes = "true" in the repo configuration of the above reproduction steps.

The described behavior is correct - modularity excludes some of the sack packages.
You can workaround it also using `flags` parameter of the query constructor:

pkglist = dnfbase.sack.query(flags=hawkey.IGNORE_MODULAR_EXCLUDES)

Now all modular excludes are going to be ignored for the query and all packages will be visible.

Thank you Marek. So this works as designed?

I am trying to use dnf to evaluate "foreign" repositories, regardless of the used local system (i.e. use a RHEL 8 system to analyse and evaluate dependencies for a RHEL9 repo; also including the RHEL9 module variations. Is this meant to be a (current or future) use case?

The way I understand it now, dnf will always be dependent on/influenced by the local setup and not a generic repository evaluation tool.

Note:
DNF has 2 types of excludes:
- regular excludes are defined in config file or cli using `exclude` or `excludepkgs`; can be ignored using flag value `hawkey.IGNORE_REGULAR_EXCLUDES`
- modular excludes set by modularity; can be ignored using flag value `hawkey.IGNORE_MODULAR_EXCLUDES`

or flag value `hawkey.IGNORE_EXCLUDES` to ignore all excludes.

Thank you Jaroslav. Is this documented anywhere? I couldn't find it (yet).

Unfortunately, flags are not documented yet. We will improve the documentation as a solution for this report.

Usage:

base.sack.query(flags=<flag>)

As a flag use one of following: hawkey.IGNORE_EXCLUDES, hawkey.APPLY_EXCLUDES, hawkey.IGNORE_REGULAR_EXCLUDES ,hawkey.IGNORE_MODULAR_EXCLUDES

hawkey.APPLY_EXCLUDES is a default behavior without any flag.

I see. Will you do it? Otherwise I am happy to raise a PR to the documentation git this evening or tomorrow.

https://github.com/rpm-software-management/dnf/pull/1807

Hello, I am not sure on the current status of this ticket.

Can you answer this question?

    "Does this work as designed?

    I am trying to use dnf to evaluate "foreign" repositories, regardless of the used local system (i.e. use a RHEL 8 system to analyse and evaluate dependencies for a RHEL9 repo;
    also including the RHEL9 module variations. Is this meant to be a (current or future) use case?

    The way I understand it now, dnf will always be dependent on/influenced by the local setup and not a generic repository evaluation tool."

1. If it works as designed: Documentation has been updated and ticket can be closed.

2. If not, we would need a fix.

Thank you and best wishes,

Stefan

I will provide some notes to your code. May be it will help to understand it.

Steps to Reproduce:
import dnf
url="http://ftp.agdsn.de/pub/mirrors/centos/7.9.2009/os/x86_64/"
yumsrc_conf="/etc/rhn/spacewalk-repo-sync/yum.conf"
dnfbase = dnf.Base()
name="test"
repo = dnf.repo.Repo(name,dnfbase.conf)
repo.mirrorlist = url
repo.baseurl = [url]
 
dnfbase.repos.add(repo)

# You do not need to load repo separately (remove following line). It is done by `dnfbase.fill_sack()
dnfbase.repos[repo.id].load()

dnfbase.fill_sack(load_system_repo=False,load_available_repos=True)

#Returns len of packages in sack.
print (len(dnfbase.sack))
# 10072


pkglist = dnfbase.sack.query()
print(len(pkglist))
# 9597
# Query contains not excluded packages therefore it can provides a different number when flag `hawkey.IGNORE_EXCLUDES`is not use for initialization of query.

Thank you very much for your patch, it is great to see community contribution => welcome in DNF community. The patch was merged and I don't see any additional issue, therefore we can mark the bug as resolved.

Hello Jaroslav,

thank you, I do understand your comments and accept that this works as designed.

Unfortunately, I cannot close tickets (or I still haven't figured out how to...). So can you please do it for me?

Best wishes,

Stefan

AC: It is a documentation update therefore I suggest sanity only.

Hello Jaroslav,

I am a bit confused on the activity on this ticket.

From my point of view, the ticket can be closed as "works as designed".

I just can't close it myself so can you please do it?
If there is a reason to keep open, that is certainly also fine. I just want to avoid you working on it if not necessary.

Best wishes,

Stefan

Hello Stefan,

we are using the bugzilla for some of our processes because it is associated with your docs update PR (https://github.com/rpm-software-management/dnf/pull/1807).
We want to keep it open for now. :)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (dnf bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7712