Created attachment 897432 [details] debugdata.tar Description of problem: When trying to upgrade Fedora 20 to Fedora Rawhide using dnf distro-sync command, I run into problems with kernel packages errors. Version-Release number of selected component (if applicable): Fedora 20 with the following fc21 packages: kernel-modules-extra-3.15.0-0.rc5.git0.1.fc21.x86_64 kernel-core-3.15.0-0.rc5.git0.1.fc21.x86_64 kernel-3.15.0-0.rc5.git0.1.fc21.x86_64 kernel-modules-3.15.0-0.rc5.git0.1.fc21.x86_64 dnf-0.5.1-1.fc21.noarch hawkey-0.4.14-1.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. Install Fedora 20 2. dnf upgrade so it's up to date (updates-testing not enabled) 3. dnf upgrade the packages listed above 4. dnf --releasever=rawhide --exclude=kernel* distro-sync Excluding kernel* because I already have 3.15.0-0.rc5 installed and running, but I don't want to install a debug kernel. Actual results: Error: problem with installed package kernel-core-3.15.0-0.rc5.git0.1.fc21.x86_64. problem with installed package kernel-modules-3.15.0-0.rc5.git0.1.fc21.x86_64 Expected results: The sync should work. Additional info:
Hello, thank you for the report. We'll take a look.
I'm pretty sure this is because the '-x' option is currently modeled as a package lock, and currently distro-sync is prioritized over locks. We need to add another type of lock that breaks the distro-sync for the corresponding package. (Both lock types have merits.)
From a user perspective, the current error message is confusing. It seems ok if instead the error were to inform that exclude and distro-sync aren't compatible; i.e. distro-sync is all or nothing. The problem goes away when I don't use exclude, and the resulting system works.
Looking.
(In reply to Michael Schröder from comment #2) > I'm pretty sure this is because the '-x' option is currently modeled as a > package lock, and currently distro-sync is prioritized over locks. We need > to add another type of lock that breaks the distro-sync for the > corresponding package. (Both lock types have merits.) Indeed, these are the problems in the attachment: problem 150429f7 info problem with installed package kernel-core-3.15.0-0.rc5.git0.1.fc21.x86_64 problem 150429f7 solution 2da63ade deljob lock pkg kernel-core-3.15.0-0.rc5.git2.9.fc21.x86_64@fedora problem 150429f7 solution 41338760 deljob lock pkg kernel-core-3.15.0-0.rc5.git2.9.fc21.x86_64@updates problem 150429f7 solution 4ba2a39a allow kernel-core-3.15.0-0.rc5.git0.1.fc21.x86_64@@System etc. This is quite severe limitation of our current exclusion mechanism and we'll have to address this in libsolv.
(In reply to Michael Schröder from comment #2) > I'm pretty sure this is because the '-x' option is currently modeled as a > package lock, and currently distro-sync is prioritized over locks. We need > to add another type of lock that breaks the distro-sync for the > corresponding package. (Both lock types have merits.) Michael, this is another thing I wanted to ask you about---are you planning some work on this? We're in a scheduling phase and could assign someone (or me) to dig deep enough to libsolv to provide the new locks.
I'll change the lock semantics so that they override distro-sync.
I just wonder whether it wouldn't be easier on both libsolv and DNF to either start using pool->considered or to be selectively dropping packages from the pool?
You could do that (preferable using pool->considered). Locking the packages has an advantage, though: when there's a dependency problem because of a locked package you can print some message to the user. You don't have that information if the solver doesn't know about the packages.
Thanks, I think that's what we are going to end up doing.
*** Bug 1121570 has been marked as a duplicate of this bug. ***
fixed in the upstream using pool->considered.
*** Bug 1135975 has been marked as a duplicate of this bug. ***
This is still happening with 0.6.1, re-opening. With "exclude=openssl*" in dnf.conf, I get errors like these: Error: package openssl-1:1.0.1i-3.fc21.x86_64 is not installable. package openssl-devel-1:1.0.1i-3.fc21.x86_64 is not installable. package openssl-libs-1:1.0.1i-3.fc21.x86_64 is not installable. package openssl-libs-1:1.0.1i-3.fc21.i686 is not installable On both distro-sync (bug 1135975) and update --best now (bug 1121570).
I have some reservations whether it is the same bug, however, Jan, can you please take a look at the new case? Hans, kindly supply the depsolve data [1]. Thank you. [1] http://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/
Created attachment 933609 [details] debugdata of a distrosync with exclude=openssl*
Hi Hans, from your depsolve data I get different result (no errors). Can you install libsolv [1] and libsolv-demo [2] special packages, run 'dnf distrosync exclude=openssl* --debugsolver', execute '/usr/bin/testsolv <debugdata_path>/testcase.t' and post the output, please? [1] https://docs.google.com/a/redhat.com/file/d/0BzxZTSitD1PqREkxMC11Y05OZFU/edit?usp=sharing [2] https://drive.google.com/a/redhat.com/file/d/0BzxZTSitD1PqYjcwTzEwRGEwclU/edit?usp=sharing
[hans@shalem ~]$ sudo dnf distro-sync --exclude=openssl* --debugsolver Error: package openssl-libs-1:1.0.1i-4.fc21.x86_64 is not installable. package openssl-libs-1:1.0.1i-4.fc21.i686 is not installable. package openssl-devel-1:1.0.1i-4.fc21.x86_64 is not installable. package openssl-1:1.0.1i-4.fc21.x86_64 is not installable [hans@shalem ~]$ /usr/bin/testsolv debugdata/testcase.t Results differ: -problem 10bfcaca info package openssl-1:1.0.1i-4.fc21.x86_64 is not installable -problem 10bfcaca solution 0d89bf24 allow openssl-1:1.0.1e-39.fc20.x86_64@@System -problem 1fa3fbf9 info package openssl-devel-1:1.0.1i-4.fc21.x86_64 is not installable -problem 1fa3fbf9 solution 048c1fe3 allow openssl-devel-1:1.0.1e-39.fc20.x86_64@@System -problem a801ca4a info package openssl-libs-1:1.0.1i-4.fc21.i686 is not installable -problem a801ca4a solution a14216ad allow openssl-libs-1:1.0.1e-39.fc20.i686@@System -problem f1aa127e info package openssl-libs-1:1.0.1i-4.fc21.x86_64 is not installable -problem f1aa127e solution 79d62d04 allow openssl-libs-1:1.0.1e-39.fc20.x86_64@@System Regards, Hans
Thanks for quick response. So we need to solve inconsistency of debugsolver output and result of testsolv first.
Hm, this is probably really a bug in DNF... Or maybe even in libsolv... "dnf distro-sync" proposes: Downgrading: keyutils-libs x86_64 1.5.9-4.fc21 fedora 44 k keyutils-libs-devel x86_64 1.5.9-4.fc21 fedora 45 k krb5-devel x86_64 1.12.2-14.fc21 updates 644 k krb5-libs x86_64 1.12.2-14.fc21 updates 838 k libcom_err x86_64 1.42.12-3.fc21 updates 45 k libcom_err-devel x86_64 1.42.12-3.fc21 updates 35 k libselinux x86_64 2.3-5.fc21 fedora 149 k libselinux-devel x86_64 2.3-5.fc21 fedora 180 k libsepol x86_64 2.3-4.fc21 fedora 168 k libsepol-devel x86_64 2.3-4.fc21 fedora 76 k libverto x86_64 0.2.6-4.fc21 fedora 21 k libverto-devel x86_64 0.2.6-4.fc21 fedora 16 k openssl x86_64 1:1.0.1k-1.fc21 updates 494 k openssl-devel x86_64 1:1.0.1k-1.fc21 updates 1.3 M openssl-libs x86_64 1:1.0.1k-1.fc21 updates 942 k pcre x86_64 8.35-8.fc21 updates 477 k pcre-devel x86_64 8.35-8.fc21 updates 535 k zlib x86_64 1.2.8-7.fc21 fedora 95 k zlib-devel x86_64 1.2.8-7.fc21 fedora 54 k naming all the packages except openssl ("dnf --exclude=openssl* distro-sync keyutils-libs-devel krb5-devel libcom_err-devel libselinux-devel libsepol-devel libverto-devel pcre-devel zlib-devel keyutils-libs krb5-libs libcom_err libselinux libsepol libverto pcre zlib") works ok: Downgrading: keyutils-libs x86_64 1.5.9-4.fc21 fedora 44 k keyutils-libs-devel x86_64 1.5.9-4.fc21 fedora 45 k krb5-devel x86_64 1.12.2-14.fc21 updates 644 k krb5-libs x86_64 1.12.2-14.fc21 updates 838 k libcom_err x86_64 1.42.12-3.fc21 updates 45 k libcom_err-devel x86_64 1.42.12-3.fc21 updates 35 k libselinux x86_64 2.3-5.fc21 fedora 149 k libselinux-devel x86_64 2.3-5.fc21 fedora 180 k libsepol x86_64 2.3-4.fc21 fedora 168 k libsepol-devel x86_64 2.3-4.fc21 fedora 76 k libverto x86_64 0.2.6-4.fc21 fedora 21 k libverto-devel x86_64 0.2.6-4.fc21 fedora 16 k pcre x86_64 8.35-8.fc21 updates 477 k pcre-devel x86_64 8.35-8.fc21 updates 535 k zlib x86_64 1.2.8-7.fc21 fedora 95 k zlib-devel x86_64 1.2.8-7.fc21 fedora 54 k But "dnf --exclude=openssl* distro-sync" fails: Error: package openssl-devel-1:1.0.1j-1.fc21.x86_64 is not installable. package openssl-1:1.0.1j-1.fc21.x86_64 is not installable. package openssl-libs-1:1.0.1j-1.fc21.x86_64 is not installable
Created attachment 1002859 [details] debugdata of dnf --assumeno distro-sync
Created attachment 1002860 [details] debugdata of dnf --exclude=openssl* distro-sync
Created attachment 1002861 [details] debugdata of dnf --debugsolver --exclude=openssl* distro-sync keyutils-libs-devel krb5-devel libcom_err-devel libselinux-devel libsepol-devel libverto-devel pcre-devel zlib-devel keyutils-l
*** Bug 1202794 has been marked as a duplicate of this bug. ***
Hawkey bug (I think). libsolv assumes that the whatprovides hash does not include packages that are excluded, i.e. you have to call createwhatprovides after changing the considered map. Running testsolv on the testcase gives you the desired result.
IMHO you should add a hy_sack_commit_excludes() function that does the pool->considered setup and the createwhatprovides call instead of doing the setup implicitly, as that may be too late.
dnf-plugins-core-0.1.7-1.fc22,hawkey-0.5.5-1.fc22,dnf-1.0.0-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/dnf-plugins-core-0.1.7-1.fc22,hawkey-0.5.5-1.fc22,dnf-1.0.0-1.fc22
Package dnf-plugins-core-0.1.7-1.fc22, hawkey-0.5.5-1.fc22, dnf-1.0.0-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-plugins-core-0.1.7-1.fc22 hawkey-0.5.5-1.fc22 dnf-1.0.0-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7483/dnf-plugins-core-0.1.7-1.fc22,hawkey-0.5.5-1.fc22,dnf-1.0.0-1.fc22 then log in and leave karma (feedback).
dnf-plugins-core-0.1.7-1.fc22, hawkey-0.5.5-1.fc22, dnf-1.0.0-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1194735 has been marked as a duplicate of this bug. ***