AlmaLinux 9: audit package sources instead of trusting priorities

Test scope

A local repo containing tree, wget and their dependencies was built inside an almalinux:9 container (AlmaLinux 9.8), then --disablerepo="*" --enablerepo=multi list available was run, repeated with includepkgs=tree, and again with excludepkgs=wget. Log: plans/content-expansion/evidence/logs/alma-repo-priority.log.

The cost option was compared on Rocky (it did not change the selection) but was not repeated on Alma; this page only documents the two tested mechanisms.

Audit the sources first

AlmaLinux enables only baseos, appstream and extras by default. Once you add EPEL, CRB, Remi or a local repo, the same package name may exist in several sources. Which build you get depends on which sources are enabled, not on which one is newer.

Start by looking:

dnf repolist --all | head -20

The enabled column tells you which sources are currently on.

Option one: pin the source per command

sudo dnf --disablerepo="*" --enablerepo=multi list available

Available Packages
libpsl.aarch64                    0.21.1-5.el9     multi
publicsuffix-list-dafsa.noarch    20210518-3.el9   multi
tree.aarch64                      1.8.0-10.el9     multi
wget.aarch64                      1.21.1-11.el9_8  multi

--disablerepo="*" turns everything off and then enables the one you name: only multi resolves, and the permanent configuration in /etc/yum.repos.d/ is untouched.

Option two: tighten what a repo exposes

[multi]
name=Multi
baseurl=file:///srv/multi
enabled=0
gpgcheck=0
includepkgs=tree

Available Packages
tree.aarch64    1.8.0-10.el9    multi

Only tree remains. The inverse uses excludepkgs=wget:

Available Packages
libpsl.aarch64                    0.21.1-5.el9     multi
publicsuffix-list-dafsa.noarch    20210518-3.el9   multi
tree.aarch64                      1.8.0-10.el9     multi

wget is excluded while the rest stays visible. Both directives take package names, not file names.

Conclusion: tighten first, talk about “priority” later

The usual trap is assuming a configuration knob decides automatically. What tested reliably:

disable everything for that command and enable one source (--disablerepo="*" --enablerepo=<id>);
keep unwanted packages out of a repo with includepkgs/excludepkgs;
when a source must be fixed long-term, set enabled=1 there and enabled=0 elsewhere so “which sources take part” becomes explicit configuration.

Common traps

Enabling permanently when you only needed it once: an enabled=1 third-party repo joins later dnf update runs;
Forgetting dnf clean all: editing a repo file while metadata is cached makes list available look unchanged;
Excluding a dependency: a too-broad excludepkgs hides required packages and the install fails on dependencies.

Practice: install only from the local source

sudo dnf --disablerepo="*" --enablerepo=multi install -y tree
rpm -q tree

Checks:

rpm -q tree prints a version
After adding includepkgs=tree to multi.repo and running dnf clean all, dnf --disablerepo="*" --enablerepo=multi list available | grep -c wget → 0
With excludepkgs=wget instead, still 0, while other packages remain visible

FAQ

常见问题

Why is the version I get different from what I expected?

dnf only resolves from currently enabled sources. A third-party or local repo may offer the same name built differently; check `dnf repolist --all`, then pin the source with --enablerepo.

Can includepkgs and excludepkgs be used together?

Yes, but the semantics get confusing: includepkgs narrows to a set and excludepkgs removes part of it. Pick one in production so you can reason about the visible set.

Is there something like yum-plugin-priorities?

EL9 default repositories do not ship a usable priority plugin (dnf-plugins-core does not include it). The reliable approach is controlling which sources are enabled and using includepkgs/excludepkgs rather than trusting a priority number.

Next steps

Repositories and SIGs: AlmaLinux repositories
Third-party sources: Third-party repos
Offline installs: Offline package installs