RFE: Strict repo priority

[opoplawski]

A big issue with testing updates to Python (and other complicated) packages in Fedora is that many packages have upper bounds to versions, which causes them to simply grab the current version of the rebuilt package from the main repository - masking the fact that updating the first package will break dependencies of the later. Another issue is packages with circular dependencies.

If dnf had a strict_repo_priority option (similar to conda's strict channel priority -https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-channels.html) where if a package existed in a higher priority repo, it would be automatically excluded from repos of lower priority, then it would be much easier to test package updates in copr.

See also fedora-copr/copr#3819

[kontura]

I believe you could use the dnf5 --from-repo option to do basically what you want (dnf4 has repository-packages command that should have similar functionality).

Can you try:

$ dnf5 upgrade --from-repo my_copr_repo '*'

?

This basically says update all installed packages that have matching name.arch package in my_copr_repo to the newer version in my_copr_repo while using the rest of enabled repos for other dependencies.
It should also work with for example install or distro-sync commands.

In order for this to work for a package some version of it has to be present in my_copr_repo but I think that would be true also for the strict priority option you suggested.

[kontura]

Another option might be to use vendors.
If you could first install all the required packages from my_copr_repo (in any version) and then set dnf option allow_vendor_change to false, dnf will ensure to only use packages of the same vendor (for example Fedora Copr - user rpmsoftwaremanagement). This should mean it won't switch back to the fedora versions.

[kontura]

Since there possibly are other approaches how to achieve the requested functionality I am closing this for now.

[opoplawski]

I'm not convinced that either of those suggestions will work for copr builds as we are doing initial installs of packages. We are not starting with any packages present.

[kontura]

I think the --from-repo approach should work assuming you don't mind installing/updating everything present in the copr repo.

I have put together an example to demonstrate.
Here is a COPR repo with incompatible packages: https://copr.fedorainfracloud.org/coprs/amatej/from-repo/: it contains librepo with major version bumped to librepo-2.1.0 and modified libdnf that has Conflicts: librepo > 2.0.0.

With this COPR enabled this does fail:

$ sudo dnf5 --installroot /tmp/test --use-host-config install --from-repo copr:copr.fedorainfracloud.org:amatej:from-repo '*'
Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
Problem 1: package libdnf-0.75.0-1.git.3304.fd610f2.fc44.x86_64 from copr:copr.fedorainfracloud.org:amatej:from-repo conflicts with librepo(x86-64) > 2.0.0 provided by librepo-2.1.0-1.git.1032.26d97b7.fc44.x86_64 from copr:copr.fedorainfracloud.org:amatej:from-repo
  - conflicting requests
 Problem 2: package libdnf-0.75.0-1.git.3304.fd610f2.fc44.x86_64 from copr:copr.fedorainfracloud.org:amatej:from-repo conflicts with librepo(x86-64) > 2.0.0 provided by librepo-2.1.0-1.git.1032.26d97b7.fc44.x86_64 from copr:copr.fedorainfracloud.org:amatej:from-repo
  - package python3-hawkey-0.75.0-1.git.3304.fd610f2.fc44.x86_64 from copr:copr.fedorainfracloud.org:amatej:from-repo requires libdnf(x86-64) = 0.75.0-1.git.3304.fd610f2.fc44, but none of the providers can be installed
  - package python3-librepo-2.1.0-1.git.1032.26d97b7.fc44.x86_64 from copr:copr.fedorainfracloud.org:amatej:from-repo requires librepo(x86-64) = 2.1.0-1.git.1032.26d97b7.fc44, but none of the providers can be installed
  - conflicting requests
 Problem 3: package libdnf-0.75.0-1.git.3304.fd610f2.fc44.x86_64 from copr:copr.fedorainfracloud.org:amatej:from-repo conflicts with librepo(x86-64) > 2.0.0 provided by librepo-2.1.0-1.git.1032.26d97b7.fc44.x86_64 from copr:copr.fedorainfracloud.org:amatej:from-repo
  - package librepo-devel-2.1.0-1.git.1032.26d97b7.fc44.x86_64 from copr:copr.fedorainfracloud.org:amatej:from-repo requires librepo(x86-64) = 2.1.0-1.git.1032.26d97b7.fc44, but none of the providers can be installed
  - package python3-libdnf-0.75.0-1.git.3304.fd610f2.fc44.x86_64 from copr:copr.fedorainfracloud.org:amatej:from-repo requires libdnf(x86-64) = 0.75.0-1.git.3304.fd610f2.fc44, but none of the providers can be installed
  - conflicting requests
You can try to add to command line:
  --allowerasing to allow removing of installed packages to resolve problems
  --skip-broken to skip uninstallable packages

The '*' is crucial because it ensures all packages from the COPR are enforced.
Doing just:

 $ sudo dnf5 --installroot /tmp/test --use-host-config install --from-repo copr:copr.fedorainfracloud.org:amatej:from-repo libdnf

can use different available librepo and doesn't report the problem.

Do I understand the usecase correctly or is there something I am missing?

[hroncok]

But we don't want to install everything from that repo and nothing from other repos. We want to install the build comps group and then the BuildRequires of packages we are building. Some of them from copr, rest from normal Fedora repos.

[kontura]

It could still use the other repos for the rest of dependencies but yea given that you don't want to install everything in the COPR repo then there probably isn't a way to do this now.

Personally I worry this use case is quite specific to justify such a new option, maybe some kind of a plugin would be more appropriate.