Description of problem: dnf seems to ignore 'priority' option set in my local repository. As a result packages from my repository which has priority=50 are replaced by packages from standard repositories (which has priority=99 - as per [1] and confirmed by [2]). Version-Release number of selected component (if applicable): # rpm -qv dnf libsolv dnf-4.2.5-2.fc30.noarch libsolv-0.7.5-1.fc30.armv7hl How reproducible: 100% Steps to Reproduce: 1. Create and enable additional dnf repository with priority=50 2. Make sure that package from repository with priority=50, has lower version that those from the standard repository. 3. Run dnf update Actual results: Packages from standard repository (with default priority=99) updates those from the additional repository (with priority=50). Expected results: Packages from additional dnf repository (with priority=50) shouldn't be updated by counterparts available in the standard repository (with default priority=99). Additional info: [2] contains the full debugdata generated by using: # dnf update --debugsolver -v dnf excerpt log: Installing dependencies: ebtables-compat armv7hl 2.0.10-35.fc30 updates 8.5 k replacing ebtables.armv7hl 2.0.10-31.fc30 ebtables-legacy armv7hl 2.0.10-35.fc30 updates 85 k ebtables-services armv7hl 2.0.10-35.fc30 updates 11 k kernel armv7hl 5.1.19-300.fc30 updates 16 k kernel-core armv7hl 5.1.19-300.fc30 updates 25 M kernel-modules armv7hl 5.1.19-300.fc30 updates 20 M kernel\* packages shouldn't be updated as those will overwrite counterparts already installed from my local smock-dw repository. [1] https://dnf.readthedocs.io/en/latest/conf_ref.html [2] https://dwrobel.fedorapeople.org/projects/bugz/dnf/debugdata-20190726/
The problem is in the combination of repository priorities and install-only packages (kernel in your case). I've filed an issue for the libsolv (https://github.com/openSUSE/libsolv/issues/343). Meanwhile (as a workaround) you could exclude kernel packages from the "updates" repository by adding this line into /etc/yum.repos.d/fedora-updates.repo: excludepkgs=kernel* I've also created minimal reporoducer for the issue: $ cat reproducer.t repo system 0 testtags <inline> #>=Pkg: k 1 0 x86_64 repo lower_priority 1 testtags <inline> #>=Pkg: k 2 0 x86_64 repo higher_priority 2 testtags <inline> #>=Pkg: k 1 0 x86_64 system x86_64 rpm system job multiversion provides k job update all packages [forcebest] result transaction,problems <inline>
(In reply to Marek Blaha from comment #1) > Meanwhile (as a workaround) you could exclude kernel packages from the > "updates" repository by adding this line into > /etc/yum.repos.d/fedora-updates.repo: > > excludepkgs=kernel* Thank you for the hint, that's a know workaround used by fedberry in many places [1], but it complicates a lot of things so I would like to get rid of that workaround here [2]. That's actually the main reason I filled this issue and I would appreciate to have it fixed. [1] https://github.com/fedberry/fedberry-repo/blob/master/fedora.repo#L13 [2] https://github.com/fedberry/fedberry-repo/pull/5
Thanks for reporting this issue - we were not aware of this before and we also want to have it fixed. The problem is probably in the underlying libsolv library so we need to coordinate with them.
The issue has been fixed in the libsolv in upstream. If you are willing to test it, you can install libsolv from our nightlies repository https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf-nightly/: # dnf copr enable rpmsoftwaremanagement/dnf-nightly # dnf update libsolv Remember, that this repo contains also nightly builds of dnf, which are not always stable enough. You can disable this repo after updating libsolv: # dnf copr disable rpmsoftwaremanagement/dnf-nightly
Created attachment 1599986 [details] rpi3-libsolv0.7.5-16g927d7259 success
Created attachment 1599988 [details] rpi4-libsolv0.7.5-16g927d7259 failure
(In reply to Marek Blaha from comment #4) > If you are willing to > test it, you can install libsolv from our nightlies repository > https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf-nightly/: As I was observing this issue on Raspberry Pi, I recompiled libsolv-0.7.5-16g927d7259 [3] in mock and added it to my local 'smock-dw' repository. After updating libsolv, the output of dnf update attachment#1599986 [details] looks ok to me (debugsolver data available here[4]). I also have another test machine which apart from repo: smock-dw,priority=50 contains one more: smock-rpi3,priority=60. However, repeating the same steps (updating libsolv followed by dnf update) failed as follows: Dependencies resolved. =================================================================================================================================================================================================================== Package Architecture Version Repository Size =================================================================================================================================================================================================================== Installing: kernel armv7hl 5.1.20-300.fc30 updates 16 k kernel-core armv7hl 5.1.20-300.fc30 updates 25 M kernel-modules armv7hl 5.1.20-300.fc30 updates 20 M Upgrading: containers-common armv7hl 1:0.1.37-2.fc30 updates 48 k libssh2 armv7hl 1.9.0-1.fc30 updates 96 k mkpasswd armv7hl 5.5.0-1.fc30 updates 39 k slirp4netns armv7hl 0.4.0-4.git19d199a.fc30 updates 72 k whois-nls noarch 5.5.0-1.fc30 updates 33 k Installing dependencies: linux-firmware noarch 20190717-99.fc30 updates 61 M Removing: kernel armv7hl 4.19.57-5.rpi.fc30 @smock-dw 0 kernel-core armv7hl 4.19.57-5.rpi.fc30 @smock-dw 46 M kernel-modules armv7hl 4.19.57-5.rpi.fc30 @smock-dw 7.3 M where kernel package shouldn't be updated. Please find attached full console output attachment#1599988 [details] as well as debugsolver data [5]. [3] https://copr-be.cloud.fedoraproject.org/results/rpmsoftwaremanagement/dnf-nightly/fedora-30-x86_64/00993099-libsolv/libsolv-0.7.5-16g927d7259.fc30.src.rpm [4] https://dwrobel.fedorapeople.org/projects/bugz/dnf/debugdata-20190802-libsolv0.7.5-16g927d7259.tar.xz [5] https://dwrobel.fedorapeople.org/projects/bugz/dnf/debugdata-failure-20190802-libsolv0.7.5-16g927d7259.tar.xz
Right. I was able to distill really simple reproducer for libsolv from your debugsolver data. I updated the libsolv issue https://github.com/openSUSE/libsolv/issues/343 with it.
There is newer version of libsolv in rpmsoftwaremanagement/dnf-nightly copr repo (libsolv-0:0.7.5-18g9bb2290c). Please, can you check if it works for your use cases?
Using libsolv version 0.7.5-18g9bb2290 [6] 'dnf update' works fine in all my use cases. The only thing which works differently is the 'Cockpit->Software Updates->Available Updates' where I still see a kernel version 5.2.7.200.fc30, but that seems to be a different issue I guess? [6] https://copr-be.cloud.fedoraproject.org/results/rpmsoftwaremanagement/dnf-nightly/fedora-30-x86_64/00997442-libsolv/libsolv-0.7.5-18g9bb2290c.fc30.src.rpm
I think, I found one more place where it doesn't work as expected. I have now two installations A (the old which I keep using since I opened this issue) and B (the new one). Both have libsolv 0.7.6 [7] installed and while the A is working fine on the B I'm observing the issue where the kernel 5.2.16 is going to be installed: [dw@rpi4-dw ~]$ rpm -qv libsolv libsolv-0.7.6-1.fc30.armv7hl [dw@rpi4-dw ~]$ sudo dnf update --debugsolver -v Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync DNF version: 4.2.8 cachedir: /var/cache/dnf Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist repo: downloading from remote: smock-dw smock dw 7.2 MB/s | 299 kB 00:00 smock-dw: using metadata from Wed 25 Sep 2019 14:03:07 EDT. repo: downloading from remote: fedora-modular Fedora Modular 30 - armhfp 1.5 MB/s | 2.6 MB 00:01 fedora-modular: using metadata from Thu 25 Apr 2019 19:44:37 EDT. repo: downloading from remote: updates-modular Fedora Modular 30 - armhfp - Updates 711 kB/s | 3.1 MB 00:04 updates-modular: using metadata from Sat 21 Sep 2019 21:30:08 EDT. repo: downloading from remote: updates Fedora 30 - armhfp - Updates 2.7 MB/s | 19 MB 00:06 updates: using metadata from Tue 24 Sep 2019 20:43:50 EDT. repo: downloading from remote: fedora Fedora 30 - armhfp 3.6 MB/s | 65 MB 00:18 fedora: using metadata from Thu 25 Apr 2019 19:49:00 EDT. Last metadata expiration check: 0:00:01 ago on Wed 25 Sep 2019 17:54:06 EDT. Completion plugin: Generating completion cache... --> Starting dependency resolution ---> Package ebtables-compat.armv7hl 2.0.10-36.fc30 will be installed ---> Package ebtables.armv7hl 2.0.10-31.fc30 will be obsoleted ---> Package ebtables-legacy.armv7hl 2.0.10-36.fc30 will be installed ---> Package ebtables-services.armv7hl 2.0.10-36.fc30 will be installed ---> Package kernel.armv7hl 5.2.16-200.fc30 will be installed ---> Package kernel-core.armv7hl 5.2.16-200.fc30 will be installed ---> Package kernel-modules.armv7hl 5.2.16-200.fc30 will be installed ---> Package linux-firmware.noarch 20190815-101.fc30 will be installed --> Finished dependency resolution Dependencies resolved. ============================================================================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================================================================== Installing dependencies: ebtables-compat armv7hl 2.0.10-36.fc30 updates 8.6 k replacing ebtables.armv7hl 2.0.10-31.fc30 ebtables-legacy armv7hl 2.0.10-36.fc30 updates 85 k ebtables-services armv7hl 2.0.10-36.fc30 updates 11 k kernel armv7hl 5.2.16-200.fc30 updates 17 k kernel-core armv7hl 5.2.16-200.fc30 updates 29 M kernel-modules armv7hl 5.2.16-200.fc30 updates 20 M linux-firmware noarch 20190815-101.fc30 updates 61 M Transaction Summary ============================================================================================================================================================================================================================================== Install 7 Packages Total download size: 110 M Is this ok [y/N]: n Operation aborted. Please find dnf debugdata available here [8]. An attempt to install ebtable-compat works as expected: dw@rpi4-dw ~]$ rpm -qv ebtables-compat package ebtables-compat is not installed [dw@rpi4-dw ~]$ sudo dnf install ebtables-compat [sudo] password for dw: smock dw 701 kB/s | 3.0 kB 00:00 Fedora Modular 30 - armhfp 38 kB/s | 23 kB 00:00 Fedora Modular 30 - armhfp - Updates 39 kB/s | 21 kB 00:00 Fedora 30 - armhfp - Updates 35 kB/s | 21 kB 00:00 Fedora 30 - armhfp 102 kB/s | 23 kB 00:00 Dependencies resolved. ============================================================================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================================================================== Installing: ebtables-compat armv7hl 2.0.10-36.fc30 updates 8.6 k replacing ebtables.armv7hl 2.0.10-31.fc30 Installing dependencies: ebtables-legacy armv7hl 2.0.10-36.fc30 updates 85 k ebtables-services armv7hl 2.0.10-36.fc30 updates 11 k Transaction Summary ============================================================================================================================================================================================================================================== Install 3 Packages Total download size: 105 k Is this ok [y/N]: n Operation aborted. I assume that once ebtables-compat will be installed the issue will not be visible as this is the case on A, where ebtables-compat version 2.0.10-36.fc30 is installed and where dnf update doesn't pull-in kernel 5.2.16. [7] https://koji.fedoraproject.org/koji/buildinfo?buildID=1367278 [8] https://dwrobel.fedorapeople.org/projects/bugz/dnf/debugdata-20190925/
I believe that DNF is no longer uses libsolv to select packages, so reassigning. Also debugdata produced by DNF is just complete garbage.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
According to issue on libsolv and a test in our CI (Scenario: Do not upgrade installonly package from lower-priority repository), the issue is resolved. I tested it on Fedora 33.