Description of problem: I just tried to install dnf-yum package. Here is the full output $sudo dnf install dnf-yum Error: package anaconda-yum-plugins-1:1.0-10.fc20.noarch requires yum, but none of the providers can be installed This doesn't give me any info to understand the dependency chain. We need this to be able to debug issues. -v doesn't help either. Similar problem https://ask.fedoraproject.org/en/question/54806/how-can-i-know-why-dnf-pulls-in-packages-or-sees-a-conflict/
dnf in f21 (0.6.x) has a better message $ sudo dnf install dnf-yum Error: package dnf-yum-0.6.1-1.fc21.noarch conflicts with yum provided by yum-3.4.3-153.fc21.noarch So I think this is allready fixed
Tim, you've got different log because you probably have no yum plugin. It's hard to tell what is the most useful output from solver perspective. Rahul, upload your debugdata [1], please. We will take a look what could be improved then. [1] http://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/
Created attachment 943365 [details] debugsolver tarball attaching the debugsolver data
Maybe I could add an illustration of the problems I mentioned in the "Ask Fedora" question Rahul referred to (and also kindly answered). When trying to experiment with a few selected packages from F21 on a system with mainly older packages, I get the following mimmi$ sudo env LANG=en_US.utf8 dnf --best --enablerepo=test{,-updates{,-testing}} upgrade octave Error: package Field3D-1.3.2-12.fc20.x86_64 requires hdf5 = 1.8.11, but none of the providers can be installed From only this output, it's not very obvious what Field3D and hdf5 have to do with octave. The machine has a nonsupported mix of packages, so it's not surprising that dnf has problems. But I don't have any way to figure out the reason using dnf. (I still have yum installed, so I can find the answer in the particular case using that.) With yum, I could study the "Processing Dependency" messages, and figure out what was going on. I upgraded dnf to the F21 version. (Somewhat hesitantly, while mix, I don't want to COMPLETELY mess up the core functions of the machine.) But it didn't give any additional information I could use, neither with "-v" nor with "--debugsolver". Would it help if I uploaded debugsolver data for this problem too? If so, in this bugzilla, or do you prefer I start a new?
I would suggest filing a new bug report with debugsolver data uploaded somewhere. Makes it easier to keep track of it just in case, they happen to be different issues.
Ok, I filed bug 1149001 about a test case of mine. (A slightly simplified version of the one in comment 4.)
For the specific example of `dnf-yum`, isn't the only way for it to work for dnf-yum to have Provides: yum ?
(In reply to Pete Travis from comment #7) > For the specific example of `dnf-yum`, isn't the only way for it to work for > dnf-yum to have Provides: yum ? No, because it don't provide yum, it dont include the yum-python api used by most programs there requires yum, it only procides /usr/bin/yum as an alias to /usr/bin/dnf so shell scricts there calls 'yum somecommand' will work in most cases.
The idea is to request processing output in case of dependency error when "--verbose" is set. IMO Libsolv provides from API only info of last error (what is seen now) and solutions. We can take advantage of /var/cache/dnf/x86_64/19/hawkey.where is logged depsolving in non-human readable format.
*** Bug 1149001 has been marked as a duplicate of this bug. ***
IIRC the solutions from libsolv are useful for determining or at least narrowing down the problem. More useful than the current "no can do" message anyway. I doubt you want them enabled by default, but perhaps the solutions could be output in verbose mode or use a dedicated switch.
*** Bug 1178248 has been marked as a duplicate of this bug. ***
*** Bug 1186027 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
sudo dnf install dnf-yum Using metadata from Wed Apr 29 18:20:29 2015 Ошибка: package dnf-yum-0.6.1-1.fc21.noarch conflicts with yum provided by yum-3.4.3-153.fc21.noarch. package yum-langpacks-0.4.5-1.fc21.noarch requires yum >= 3.0, but none of the providers can be installed
*** Bug 1225725 has been marked as a duplicate of this bug. ***
*** Bug 1195106 has been marked as a duplicate of this bug. ***
*** Bug 1227238 has been marked as a duplicate of this bug. ***
*** Bug 1260252 has been marked as a duplicate of this bug. ***
I just ran into this on a new F23 beta install: [root@ian ~]# dnf remove NetworkManager Dependencies resolved. ================================================================================================================================================================== Package Arch Version Repository Size ================================================================================================================================================================== Removing: NetworkManager x86_64 1:1.0.6-4.fc23 @System 9.2 M NetworkManager-libnm x86_64 1:1.0.6-4.fc23 @System 1.5 M avahi-autoipd x86_64 0.6.31-37.fc23 @System 44 k cln x86_64 1.3.4-3.fc23 @System 1.6 M dnsmasq x86_64 2.72-4.fc23 @System 581 k f23-backgrounds-kde noarch 23.0.1-1.fc23 @System 211 f23-kde-theme noarch 23.0-4.fc23 @System 4.4 M kde-platform-plugin x86_64 1:4.11.21-1.fc23 @System 48 k kde-print-manager x86_64 15.04.2-3.fc23 @System 786 k kde-print-manager-libs x86_64 15.04.2-3.fc23 @System 595 k kde-settings-plasma noarch 23-3.fc23 @System 2.7 k kf5-kactivities x86_64 5.13.0-1.fc23 @System 926 k kf5-kdewebkit x86_64 5.13.0-1.fc23 @System 206 k kf5-kdoctools x86_64 5.13.0-1.fc23 @System 2.2 M kf5-kjsembed x86_64 5.13.0-1.fc23 @System 1.7 M kf5-kpeople x86_64 5.13.0-1.fc23 @System 458 k kf5-kxmlrpcclient x86_64 5.13.0-1.fc23 @System 122 k kf5-networkmanager-qt x86_64 5.13.0-1.fc23 @System 1.3 M khotkeys x86_64 5.4.0-1.fc23 @System 2.4 M kio-extras x86_64 15.08.0-1.fc23 @System 1.7 M kmenuedit x86_64 5.4.0-1.fc23 @System 1.3 M kwayland-integration x86_64 5.4.0-1.fc23 @System 90 k kwrited x86_64 5.4.0-1.fc23 @System 64 k libXaw x86_64 1.0.13-2.fc23 @System 488 k libndp x86_64 1.5-2.fc23 @System 73 k libqalculate x86_64 0.9.7-14.fc23 @System 5.5 M oxygen-sound-theme noarch 5.4.0-1.fc23 @System 1.9 M plasma-desktop x86_64 5.4.0-1.fc23 @System 27 M plasma-milou x86_64 5.4.0-1.fc23 @System 245 k plasma-pa x86_64 5.4.0-1.fc23 @System 439 k plasma-workspace x86_64 5.4.0-4.fc23 @System 31 M powerdevil x86_64 5.4.0-1.fc23 @System 2.0 M qt5-qtquickcontrols x86_64 5.5.0-2.fc23 @System 3.5 M qt5-qttools x86_64 5.5.0-4.fc23 @System 82 k sddm-breeze noarch 5.4.0-4.fc23 @System 796 k xorg-x11-apps x86_64 7.7-14.fc23 @System 870 k xorg-x11-fonts-misc noarch 7.5-15.fc23 @System 6.8 M xorg-x11-xbitmaps noarch 1.1.1-8.fc23 @System 179 k Transaction Summary ================================================================================================================================================================== Remove 38 Packages Installed size: 112 M Is this ok [y/N]: AFAICT, there is no way to get dnf (or any other tool in F23) to provide me with detailed dependency information.
Ian - I think that is an entirely separate issue. dnf is removing the packages that were only brought in by NetworkManager when it was installed, and so should no longer be needed. This is enabled by default with the following in /etc/dnf/dnf.conf: clean_requirements_on_remove=true
(In reply to Orion Poplawski from comment #21) > Ian - I think that is an entirely separate issue. dnf is removing the > packages that were only brought in by NetworkManager when it was installed, > and so should no longer be needed. This is enabled by default with the > following in /etc/dnf/dnf.conf: > > clean_requirements_on_remove=true I don't think it's a separate issue, because the issue is not that dnf is removing the additional packages; the issue is that I can't get dnf to tell me *why* it's removing those packages. I ended up using repeated "rpm -e ..." commands to figure out that it's https://bugzilla.redhat.com/show_bug.cgi?id=1222097, but having to waste my time doing that is a huge step back from the detailed dependency chain information that yum provided.
*** Bug 1262869 has been marked as a duplicate of this bug. ***
Isn't this a duplicate of 1084129?
For some reason the depsolving information is much clearer when doing 'dnf update --best' than 'dnf update --verbose' even though one would think that --verbose would be verbose. Compare the following output: # dnf update --verbose Last metadata expiration check performed 0:09:26 ago on Fri Sep 18 06:59:32 2015. ... --> Starting dependency resolution --> Finished dependency resolution Dependencies resolved. langpacks: enabled languages are ['en', 'ja'] ================================================================================ Package Arch Version Repository Size ================================================================================ Skipping packages with broken dependencies: xorg-x11-drv-ati x86_64 7.6.0-0.4.20150729git5510cd6.fc23 updates-testing 155 k xorg-x11-drv-dummy x86_64 0.3.6-24.fc23 updates-testing 21 k xorg-x11-drv-evdev x86_64 2.9.99-2.20150807git66c997886.fc23 updates-testing 53 k xorg-x11-drv-fbdev x86_64 0.4.3-23.fc23 updates-testing 24 k xorg-x11-drv-intel x86_64 2.99.917-16.20150729.fc23 updates-testing 677 k xorg-x11-drv-openchrome x86_64 0.3.3-17.fc23 updates-testing 175 k xorg-x11-drv-qxl x86_64 0.1.4-6.fc23 updates-testing 97 k xorg-x11-drv-sisusb x86_64 0.9.6-22.fc23 updates-testing 50 k xorg-x11-drv-synaptics x86_64 1.8.2-4.fc23 updates-testing 93 k xorg-x11-drv-v4l x86_64 0.2.0-45.fc23 updates-testing 25 k xorg-x11-drv-vesa x86_64 2.3.2-23.fc23 updates-testing 29 k xorg-x11-drv-vmmouse x86_64 13.1.0-2.fc23 updates-testing 29 k xorg-x11-drv-vmware x86_64 13.0.2-10.20150211git8f0cf7c.fc23 updates-testing 84 k xorg-x11-drv-voodoo x86_64 1.2.5-23.fc23 updates-testing 25 k xorg-x11-drv-wacom x86_64 0.30.0-3.fc23 updates-testing 304 k xorg-x11-server-Xorg x86_64 1.18.0-0.2.20150907.fc23 updates-testing 1.4 M Transaction Summary ================================================================================ Nothing to do. Absolutely no information as to why those packages were skipped. OTOH: # dnf update --best Last metadata expiration check performed 0:13:23 ago on Fri Sep 18 06:59:32 2015. Error: package xorg-x11-drv-nouveau-1:1.0.11-4.fc23.x86_64 requires xserver-abi(videodrv-19) >= 0, but none of the providers can be installed. package xorg-x11-drv-nouveau-1:1.0.11-4.fc23.x86_64 requires xserver-abi(videodrv-19) >= 0, but none of the providers can be installed. package xorg-x11-drv-nouveau-1:1.0.11-4.fc23.x86_64 requires xserver-abi(videodrv-19) >= 0, but none of the providers can be installed. package xorg-x11-drv-nouveau-1:1.0.11-4.fc23.x86_64 requires xserver-abi(videodrv-19) >= 0, but none of the providers can be installed (try to add '--allowerasing' to command line to replace conflicting packages)
I've been getting this for a week or so now, no indication of what the dependency problem is, just that there is one: [root@zooty ~]# dnf update Last metadata expiration check performed 0:00:02 ago on Sun Sep 20 09:02:41 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Skipping packages with broken dependencies: lilypond-fonts-common noarch 2.19.26-1.fc22 updates 31 k Transaction Summary ================================================================================ Nothing to do.
See bug 1264672 for an example of how yum-deprecated provides enough info to see what is going on, versus the dnf technique of just saying "there was a problem".
*** Bug 1263371 has been marked as a duplicate of this bug. ***
*** Bug 1277140 has been marked as a duplicate of this bug. ***
*** Bug 1281596 has been marked as a duplicate of this bug. ***
Updating this to rawhide as now that dnf is live for builds in koji it's causing further issues in fixing build issues
Some days ago I had a similar problem: # dnf upgrade Last metadata expiration check performed 0:00:00 ago on Tue Nov 10 21:21:29 2015. Abhängigkeiten sind aufgelöst. ========================================================================================================== Paket Arch Version Paketquelle Größe ========================================================================================================== Skipping packages with broken dependencies: apper x86_64 0.9.2-3.fc22 updates 931 k Transaktionsübersicht ========================================================================================================== Nichts zu tun. Komplett! In comparison PackageKit actually had more meaningful infos for the user: # pkcon update apper Auflösen [=========================] Starten [=========================] Änderungen werden getestet [=========================] Fertig [=========================] Schwerwiegender Fehler: Could not depsolve transaction; 1 problem detected: 0. nothing provides kde-runtime >= 15.08.2 needed by apper-0.9.2-3.fc22.x86_64
(In reply to Peter Robinson from comment #31) > Updating this to rawhide as now that dnf is live for builds in koji it's > causing further issues in fixing build issues like in http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2989622 ... DEBUG util.py:468: Executing command: ['/usr/bin/dnf', 'builddep', '--installroot', '/var/lib/mock/f24-build-782078-593241/root/', '/var/lib/mock/f24-build-782078-593241/root//builddir/build/SRPMS/freesteam-2.1-10.20150903svn761.fc24.src.rpm', '--setopt=tsflags=nocontexts'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'LC_MESSAGES': 'C', 'PROMPT_COMMAND': 'printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/builddir', 'HOSTNAME': 'mock'} and shell False DEBUG util.py:393: Using metadata from Mon Dec 14 09:45:22 2015 (0:01:58 hours old) DEBUG util.py:393: Error: package ascend-devel-0.9.10-4.20151003svn3100.fc24.ppc64 requires libascend.so.1()(64bit), but none of the providers can be installed DEBUG util.py:515: Child return code was: 1 DEBUG util.py:172: kill orphans ... but the ascend package provides library (http://ppc.koji.fedoraproject.org/koji/rpminfo?rpmID=2620814), so it might be deeper in the dependency chain, but almost without a chance to identify it for a koji user
(In reply to Dan Horák from comment #33) > DEBUG util.py:393: Error: package > ascend-devel-0.9.10-4.20151003svn3100.fc24.ppc64 requires > libascend.so.1()(64bit), but none of the providers can be installed > ... > but the ascend package provides library > (http://ppc.koji.fedoraproject.org/koji/rpminfo?rpmID=2620814), so it might > be deeper in the dependency chain, but almost without a chance to identify > it for a koji user some package is in partial solution which conflicts with requirement or the requirement could not be satisfied. Figuring out which package is in conflict could be done by adding `--allowerasing --assumeno` flag. (not applicable for koji though) We would like to fix this but this task is for a long run - to get partial solutions printed out and reporting more informative error. We definitely know about this downside of DNF and it is on our priority list.
*** Bug 1213995 has been marked as a duplicate of this bug. ***
*** Bug 1303978 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
There is currently a multiarch problem in the f23 repos with sqlite. I'm getting several reports from confused and frustrated users. I see the targeting as a must-fix for F25, but I'm hoping we can do better than that. For now, a workaround is to run `yum-deprecated upgrade` and see what _it_ says.
Specifically, here is the difference in the output produced by dnf and yum-deprecated when faced with a dependency issue like this current sqlite multilib problem: $ sudo dnf upgrade Last metadata expiration check performed 2:26:20 ago on Thu Feb 25 06:28:18 2016. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Skipping packages with broken dependencies: sqlite x86_64 3.11.0-1.fc23 updates 484 k Transaction Summary ================================================================================ Skip 1 Package Nothing to do. Complete! $ sudo yum-deprecated upgrade Yum command has been deprecated, use dnf instead. See 'man dnf' and 'man yum2dnf' for more information. Loaded plugins: langpacks Resolving Dependencies --> Running transaction check ---> Package sqlite.x86_64 0:3.10.2-1.fc23 will be updated --> Processing Dependency: libsqlite3.so.0()(64bit) for package: PackageKit-glib-1.0.11-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: telepathy-gabble-0.18.2-5.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: PackageKit-command-not-found-1.0.11-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: rygel-0.28.2-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: grilo-plugins-0.2.17-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: 1:folks-0.11.1-3.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: uim-1.8.6-8.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: gnome-dvb-daemon-0.2.90-4.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: colord-1.2.12-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: libgpod-0.8.3-10.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: redland-1.0.17-4.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: evolution-data-server-3.18.5-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: xmms2-0.8-29.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: libsoup-2.52.2-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: gom-0.3.1-2.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: seed-3.8.1-6.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: subversion-1.9.3-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: libchamplain-0.12.11-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: qt5-qtwebkit-5.5.1-4.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: PackageKit-1.0.11-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: shotwell-0.23.0-0.1.20160105gitf2fb1f7.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: python-libs-2.7.10-8.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: tracker-1.6.1-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: 1:qt-4.8.7-5.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: gnome-shell-3.18.3-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: yum-metadata-parser-1.1.4-15.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: thunderbird-38.6.0-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: python3-libs-3.4.3-5.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: ibus-gucharmap-1.4.0-12.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: systemtap-devel-2.9-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: webkitgtk3-2.4.9-3.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: createrepo_c-0.10.0-2.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: systemtap-client-2.9-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: telepathy-logger-0.8.2-2.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: firefox-44.0.2-3.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: webkitgtk-2.4.9-3.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: qt5-qtbase-5.5.1-11.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: ibus-libpinyin-1.7.4-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: telepathy-salut-0.8.1-8.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: subversion-libs-1.9.3-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: libchewing-0.4.0-5.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: WritRecogn-0.1.9-12.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: nss-softokn-3.22.0-1.0.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: 2:yelp-3.17.2-3.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: filezilla-3.14.1-2.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: createrepo_c-libs-0.10.0-2.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: akonadi-1.13.0-20.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: qtwebkit-2.3.4-8.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: zeitgeist-libs-0.9.16-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: setools-libs-3.3.8-8.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: 1:nfs-utils-1.3.3-6.rc3.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: 2:yelp-libs-3.17.2-3.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: xulrunner-40.0-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: hugin-base-2015.0.0-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: PackageKit-gstreamer-plugin-1.0.11-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: webkitgtk4-2.10.7-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: simple-scan-3.18.2-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: gnome-packagekit-3.18.0-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: deja-dup-34.1-1.fc23.x86_64 --> Processing Dependency: libsqlite3.so.0()(64bit) for package: hugin-2015.0.0-1.fc23.x86_64 ---> Package sqlite.x86_64 0:3.11.0-1.fc23 will be an update --> Running transaction check ---> Package sqlite-libs.x86_64 0:3.11.0-1.fc23 will be installed --> Finished Dependency Resolution Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing out that there is a problem. Eg.: 1. You have an upgrade for sqlite which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of sqlite of the different architecture. If you exclude the bad architecture yum will tell you what the root cause is (which package requires what). You can try redoing the upgrade with --exclude sqlite.otherarch ... this should give you an error message showing the root cause of the problem. 2. You have multiple architectures of sqlite installed, but yum can only see an upgrade for one of those architectures. If you don't want/need both architectures anymore then you can remove the one with the missing update and everything will work. 3. You have duplicate versions of sqlite installed already. You can use "yum check" to get yum show these errors. ...you can also use --setopt=protected_multilib=false to remove this checking, however this is almost never the correct thing to do as something else is very likely to go wrong (often causing much more problems). Protected multilib versions: sqlite-3.11.0-1.fc23.x86_64 != sqlite-3.10.2-1.fc23.i686 As we can see, with dnf the failure is utterly mysterious, giving the user no idea of how to even begin trying to solve the problem. The yum output clearly indicates a multilib conflict, which is helpful for pointing the user to possible solutions.
Maybe dnf could just run yum-deprecated automatically when it has a dependency problem and have yum print the useful info. That could maybe be a stop-gap till dnf can become useful.
@Tom: That's going to break so much stuff and drag Python 2 back in as a dependency. The real answer is to get DNF to print out the decision tree after it's been made, and process it to return a useful error message.
@dnf developers, this was filed a long time back with a lot of duplicates and there seems to be very little if any recent feedback from developers on this issue. Could you folks kindly provide a response? Thanks
Rahul, there was a our feedback. FYI somebody is working on this feature right now.
(In reply to Jan Silhan from comment #43) > Rahul, there was a our feedback. FYI somebody is working on this feature > right now. Jan: what is the status of this? This is still causing rel-eng daily pain as we discussed back in Feb.
*** Bug 1340605 has been marked as a duplicate of this bug. ***
Peter, I understand - this is important for everyone. we had one member working on this but she no longer works on DNF. I have allocated another team member who should take over the work. For successfully resolved transaction there was made an improvement - DNF-2.0 (to be released) shows additionally in separate section which package was installed as a weak dependency and which package was removed as unneeded dependency. we still need to make this functionality available for partially resolved transactions and print which package pulled into transaction which package.
There was an update to libsolv in rawhide today to libsolv-0.6.21-2.fc25.x86_64, but libsolv still fails to show any dependency problems when asking it to solve an update for firefox. I'm checking this independently of dnf, using the python3-solv package (also updated today) and dnf_skipped.py program from https://bugzilla.redhat.com/show_bug.cgi?id=1340605, using the latest repo data. dnf is still skipping the firefox update. =><=
*** Bug 1350071 has been marked as a duplicate of this bug. ***
Jan, could we have another update on this? Not only is it continuing to cause problems for release engineering (Peter estimates several hours lost per week!), I consistently see user feedback like https://www.reddit.com/r/Fedora/comments/4wlv1e/getting_dnf_to_do_dependencies_like_yum_did/.
Hi Matthew, Michael Mraka started working on this. Hopefully, there will be some progress soon.
Libsolv has an ability report "solutions" for failed dependencies. I.E. suggests changes which may lead to a successful transaction - e.g. for installation of pkgA remove pkgB or install lower version of pkgA - this is a bit different what yum did - it reported failed dependency and a chain of packages which lead to it. The plan is to open up this information in libhif (and create python bindings for it so it can be passed to dnf. So far there's a basic prototype which still needs a bit tuning. Hopefully there'll be something usable including python bindings before dnf 2.0 is out.
(In reply to Michael Mráka from comment #51) > Libsolv has an ability report "solutions" for failed dependencies. > I.E. suggests changes which may lead to a successful transaction - e.g. for > installation of pkgA remove pkgB or install lower version of pkgA - this > is a bit different what yum did - it reported failed dependency and a > chain of packages which lead to it. Can you provide more details as to the "solutions" reports to ensure this is actually going to be useful. We need to know the explicit reason a transaction is failing so that EXPLICIT problem can be fixed. For example when doing the composes the other day on PPC we had the error below yet the version of dnf available was 1.1.9 and it was some other issue in the dep chain causing the problem: DEBUG util.py:421: package lorax-25.12-1.fc26.ppc64le requires python3-dnf >= 1.1.7, but none of the providers can be installed DEBUG util.py:421: (try to add '--allowerasing' to command line to replace conflicting packages)
> Can you provide more details as to the "solutions" reports to ensure this is > actually going to be useful. We need to know the explicit reason a > transaction is failing so that EXPLICIT problem can be fixed. E.g. dnf install sqlite-3.11.0-3.fc24.i686 Last metadata expiration check: 0:07:59 ago on Wed Aug 17 12:32:33 2016. Error: package sqlite-3.11.0-3.fc24.i686 requires sqlite-libs = 3.11.0-3.fc24, but none of the providers can be installed. Possible solutions: Allow replacement of sqlite-libs-3.13.0-1.fc24.x86_64 with sqlite-libs-3.11.0-3.fc24.x86_64 Allow replacement of sqlite-3.13.0-1.fc24.x86_64 with sqlite-3.11.0-3.fc24.x86_64 Allow installation of sqlite-libs-3.11.0-3.fc24.i686 Do not install sqlite.i686 = 3.11.0-3.fc24
I have reservations that is going to provide enough information in koji build roots. We really do need the full verbose output similar to what yum use to provide.
I am providing more information. The feature mentioned in comment 53 should be implemented by ~mid of October in DNF-2.0 only. DNF-2.0 is targeted for F26 and could be released in lower Fedora versions later if there are no crashes with components depending on DNF. Peter, the solution from Michael should bring at least some improvement in debugging. We aim to provide all dependency tree of transaction as it is in yum and this is the first step. We will improve it iteratively.
(In reply to Michael Mráka from comment #53) I am sorry, but I don't understand the message: "Allow replacement of sqlite-libs-3.13.0-1.fc24.x86_64 with sqlite-libs-3.11.0-3.fc24.x86_64" If you said there is 5 packages on the system which requires sqlite-libs-3.13.0-1.fc24.x86_64 and hence you cannot just replace it with different version, than this would be probably helpful, but I don't even know from that message how I should "allow replacement", since I did not actively prohibited it ... "Allow installation of sqlite-libs-3.11.0-3.fc24.i686" Yes! Yes! Yes! That is what was requested by the command: "dnf install sqlite-3.11.0-3.fc24.i686", what else I can do than? Why I am asked again to allow something?
(In reply to Vít Ondruch from comment #56) > (In reply to Michael Mráka from comment #53) > I am sorry, but I don't understand the message: libsolv solutions are a not entirely unlike machine translations from the eighties. You need to realize they're really just thinly veiled logical expressions outputted by the SAT solve process. "Do not install foo" is a perfectly sensible mathematical solution to avoiding problems caused by install of foo, but it doen't make much sense when presented that way to the user who specifically asked to install foo. Libsolv has a higher level of knowledge about dependency problems and their solutions than yum ever did, but its just not very good at expressing them to us poor humans :)
https://github.com/rpm-software-management/libhif/pull/177 https://github.com/rpm-software-management/dnf/pull/566
(In reply to Panu Matilainen from comment #57) > You need to realize they're really just thinly veiled logical expressions > outputted by the SAT solve process. "Do not install foo" is a perfectly > sensible mathematical solution to avoiding problems caused by install of > foo, but it doen't make much sense when presented that way to the user who > specifically asked to install foo. Libsolv has a higher level of knowledge > about dependency problems and their solutions than yum ever did, but its > just not very good at expressing them to us poor humans :) Software exists to serve "us poor humans". If it can't communicate with us it's poor software. This bug has been open for 23 months, and today I'm getting this: $ sudo dnf --verbose update cachedir: /var/cache/dnf Loaded plugins: generate_completion_cache, builddep, noroot, playground, protected_packages, download, config-manager, Query, copr, reposync, debuginfo-install, needs-restarting DNF version: 1.1.10 repo: using cache for: rpmfusion-nonfree-updates not found deltainfo for: RPM Fusion for Fedora 23 - Nonfree - Updates not found updateinfo for: RPM Fusion for Fedora 23 - Nonfree - Updates repo: using cache for: updates repo: using cache for: rpmfusion-free not found deltainfo for: RPM Fusion for Fedora 23 - Free not found updateinfo for: RPM Fusion for Fedora 23 - Free repo: using cache for: rpmfusion-nonfree not found deltainfo for: RPM Fusion for Fedora 23 - Nonfree not found updateinfo for: RPM Fusion for Fedora 23 - Nonfree repo: using cache for: bluejeans not found deltainfo for: Blue Jeans Network, Inc. - x86_64 software and updates not found updateinfo for: Blue Jeans Network, Inc. - x86_64 software and updates repo: using cache for: rpmfusion-free-updates not found deltainfo for: RPM Fusion for Fedora 23 - Free - Updates not found updateinfo for: RPM Fusion for Fedora 23 - Free - Updates repo: using cache for: fedora not found deltainfo for: Fedora 23 - x86_64 not found updateinfo for: Fedora 23 - x86_64 repo: using cache for: google-chrome not found deltainfo for: google-chrome not found updateinfo for: google-chrome rpmfusion-nonfree-updates: using metadata from Sat Sep 3 02:11:39 2016. updates: using metadata from Tue Sep 6 18:37:29 2016. rpmfusion-free: using metadata from Mon Jun 20 07:49:13 2016. rpmfusion-nonfree: using metadata from Mon Jun 20 07:18:01 2016. bluejeans: using metadata from Wed Sep 7 22:07:27 2016. rpmfusion-free-updates: using metadata from Sat Sep 3 01:56:02 2016. fedora: using metadata from Sat Oct 31 10:34:41 2015. google-chrome: using metadata from Wed Sep 7 15:28:20 2016. Last metadata expiration check: 0:07:59 ago on Thu Sep 8 09:53:25 2016. --> Starting dependency resolution ---> Package gnupg2.x86_64 2.1.13-1.fc23 will be upgraded ---> Package gnupg2.x86_64 2.1.13-2.fc23 will be an upgrade ---> Package google-chrome-stable.x86_64 53.0.2785.92-1 will be upgraded ---> Package google-chrome-stable.x86_64 53.0.2785.101-1 will be an upgrade ---> Package libgcrypt.x86_64 1.6.5-1.fc23 will be upgraded ---> Package libgcrypt.x86_64 1.6.6-1.fc23 will be an upgrade ---> Package libksba.x86_64 1.3.4-1.fc23 will be upgraded ---> Package libksba.x86_64 1.3.5-1.fc23 will be an upgrade ---> Package nss.x86_64 3.25.0-1.2.fc23 will be upgraded ---> Package nss.x86_64 3.26.0-1.0.fc23 will be an upgrade ---> Package nss-softokn.x86_64 3.25.0-1.0.fc23 will be upgraded ---> Package nss-softokn.x86_64 3.26.0-1.0.fc23 will be an upgrade ---> Package nss-util.x86_64 3.25.0-1.0.fc23 will be upgraded ---> Package nss-util.x86_64 3.26.0-1.0.fc23 will be an upgrade ---> Package nss-softokn-freebl.x86_64 3.25.0-1.0.fc23 will be upgraded ---> Package nss-softokn-freebl.x86_64 3.26.0-1.0.fc23 will be an upgrade ---> Package nss-tools.x86_64 3.25.0-1.2.fc23 will be upgraded ---> Package nss-tools.x86_64 3.26.0-1.0.fc23 will be an upgrade ---> Package nss-sysinit.x86_64 3.25.0-1.2.fc23 will be upgraded ---> Package nss-sysinit.x86_64 3.26.0-1.0.fc23 will be an upgrade --> Finished dependency resolution Dependencies resolved. ======================================================================================================================= Package Arch Version Repository Size ======================================================================================================================= Upgrading: gnupg2 x86_64 2.1.13-2.fc23 updates 1.9 M google-chrome-stable x86_64 53.0.2785.101-1 google-chrome 47 M libgcrypt x86_64 1.6.6-1.fc23 updates 377 k libksba x86_64 1.3.5-1.fc23 updates 129 k nss x86_64 3.26.0-1.0.fc23 updates 849 k nss-softokn x86_64 3.26.0-1.0.fc23 updates 383 k nss-softokn-freebl x86_64 3.26.0-1.0.fc23 updates 222 k nss-sysinit x86_64 3.26.0-1.0.fc23 updates 58 k nss-tools x86_64 3.26.0-1.0.fc23 updates 496 k nss-util x86_64 3.26.0-1.0.fc23 updates 83 k Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): gnupg2-smime x86_64 2.1.13-2.fc23 updates 406 k Transaction Summary ======================================================================================================================= Upgrade 10 Packages Skip 1 Package Total download size: 52 M Is this ok [y/N]: No, this is not OK.
https://github.com/rpm-software-management/libhif/pull/191 https://github.com/rpm-software-management/dnf/pull/616 new error msg looks like: dnf install libreoffice gimp -x xml-commons-apis,xdg-utils Last metadata expiration check: 0:56:40 ago on Tue Sep 20 14:31:28 2016 CEST. Error: Problem 0: conflicting requests - nothing provides xdg-utils needed by gimp-2:2.8.16-1.fc24.1.x86_64 - nothing provides xdg-utils needed by gimp-2:2.8.18-1.fc24.x86_64 Problem 1: conflicting requests - package libreoffice-1:5.1.3.2-6.fc24.x86_64 requires libreoffice-base(x86-64) = 1:5.1.3.2-6.fc24, but none of the providers can be installed - package libreoffice-1:5.1.5.2-6.fc24.x86_64 requires libreoffice-base(x86-64) = 1:5.1.5.2-6.fc24, but none of the providers can be installed - package libreoffice-base-1:5.1.3.2-6.fc24.x86_64 requires pentaho-reporting-flow-engine, but none of the providers can be installed - package libreoffice-base-1:5.1.5.2-6.fc24.x86_64 requires pentaho-reporting-flow-engine, but none of the providers can be installed - package pentaho-reporting-flow-engine-1:0.9.4-12.fc24.noarch requires liblayout >= 0.2.10, but none of the providers can be installed - nothing provides xml-commons-apis needed by liblayout-0.2.10-12.fc24.noarch (try to add '--allowerasing' to command line to replace conflicting packages)
> new error msg looks like: That's not useful for debugging of failing koji builds. We need to see explicitly what's broken... the "but none of the providers can be installed" tells us nothing about what's actually broken.
(In reply to Peter Robinson from comment #61) > That's not useful for debugging of failing koji builds. We need to see > explicitly what's broken... the "but none of the providers can be installed" > tells us nothing about what's actually broken. Well, the error message says: - gimp fails to install because of missing xdg-utils, - libreoffice fails to install because of missing xml-commons-apis. What kind of more explicit information would you like to see?
(In reply to Michael Mráka from comment #62) > (In reply to Peter Robinson from comment #61) > > That's not useful for debugging of failing koji builds. We need to see > > explicitly what's broken... the "but none of the providers can be installed" > > tells us nothing about what's actually broken. > > Well, the error message says: > - gimp fails to install because of missing xdg-utils, > - libreoffice fails to install because of missing xml-commons-apis. > What kind of more explicit information would you like to see? let's make an example with a dependency chain: gimp -> foo -> bar -> xdg-utils -> libabc.so.4 So if the xdg-utils are completely missing in the repo, then it's OK. If xdg-utils can't be installed because we have already have libabc.so.5, but xdg-utils Requires: libabc.so.4, then it's not. yum reported: you want xdg-utils, but it can't be installed because it requires libabc.so.4, possible candidate "libabc provides lib.so.5", or something similar. Currently dnf says "can't install gimp", the top-level problem, we need the bottom of the problem.
> Currently dnf says "can't install gimp", the top-level problem, we need the > bottom of the problem. We need the whole problem from top to bottom, and everything in between. Thanks, Dan's outline is spot on.
I think the problem is that the example is different from what happens in a real scenario (if xml-commons-apis & xdg-utils are not already installed), because these packages are excluded (so, "nothing provides xml-commons-apis" is the actual problem, since it is excluded from the repos). Michael: It would be great if you can provide a sample output for an example like what Dan said, which is actually what usually happens. So, the dependency should be available, but not installable.
(In reply to Dan Horák from comment #63) > Currently dnf says "can't install gimp", the top-level problem, we need the > bottom of the problem. That's what new error msg says: nothing provides xml-commons-apis (In reply to Hedayat Vatankhah from comment #65) > I think the problem is that the example is different from what happens in a > real scenario (if xml-commons-apis & xdg-utils are not already installed), > because these packages are excluded (so, "nothing provides xml-commons-apis" > is the actual problem, since it is excluded from the repos). They are excluded in the example which is the very same situation as if they were missing in the repo. > Michael: It would be great if you can provide a sample output for an example > like what Dan said, which is actually what usually happens. So, the > dependency should be available, but not installable. dnf-2 install libreoffice Last metadata expiration check: 0:00:00 ago on Wed Sep 21 08:28:29 2016 CEST. Error: package libreoffice-writer-1:5.1.5.2-6.fc24.x86_64 requires libcomphelper.so()(64bit), but none of the providers can be installed - package libreoffice-1:5.1.5.2-6.fc24.x86_64 requires libreoffice-writer(x86-64) = 1:5.1.5.2-6.fc24, but none of the providers can be installed - package libreoffice-core-1:5.1.5.2-6.fc24.x86_64 requires libgstpbutils-1.0.so.0()(64bit), but none of the providers can be installed - conflicting requests - nothing provides libtheoradec.so.1()(64bit) needed by gstreamer1-plugins-base-1.8.3-1.fc24.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages)
Thanks Michael, I think we can consider the problem as solved :-) A little nitpick would be about readability (compared to the info yum provided), but the information is there if I see correctly. The bottom of the problem is gstreamer1-plugins-base vs. libtheora which points to what needs to be fixed and then "magically" the upper problems will go away.
Sorry, but I don't understand completely. Why libcomphelper.so cannot be installed? And why nothing provides libtheoradec.so.1?
(In reply to Hedayat Vatankhah from comment #68) > Sorry, but I don't understand completely. Why libcomphelper.so cannot be > installed? And why nothing provides libtheoradec.so.1? for libtheoradec.so.1 it is usually simple - the libtheora package has been updated and already provides eg. libtheoradec.so.2 as soname and users of libtheora hasn't been rebuilt yet
(In reply to Hedayat Vatankhah from comment #68) > Sorry, but I don't understand completely. Why libcomphelper.so cannot be > installed? And why nothing provides libtheoradec.so.1? libcomphelper.so()(64bit) is a part of libreoffice-core which can't be installed because it requires libgstpbutils-1.0.so.0()(64bit) which is part of gstreamer1-plugins-base which can't be installed because it requires libtheoradec.so.1()(64bit) which is not available in any package (it's a part of libtheora package which is missing from the test repo I used to show the error messages).
(In reply to Michael Mráka from comment #70) > libcomphelper.so()(64bit) is a part of libreoffice-core > which can't be installed because it requires libgstpbutils-1.0.so.0()(64bit) > which is part of gstreamer1-plugins-base > which can't be installed because it requires libtheoradec.so.1()(64bit) > which is not available in any package Thanks. I think it'd be great if DNF would also provide a list of providers which can't be installed (e.g. libreoffice-core for libcomphelper). And also, I don't know what does this mean: "conflicting requests". I can't figure out what requests are conflicting. If I'm not alone in this regard, I'd suggest either removing it completely or providing a better (more complete?) message. Regards
Igor, is this going to hit F25 as well? Or something to look forward to for F26?
Created attachment 1237818 [details] dnf install output I don't see any of this "explanation" information in the following command that I run with dnf-2.0.0-2.fc26.noarch: ``` dnf install --releasever=rawhide --nogpgcheck --setopt=install_weak_deps=False --debuglevel=10 --installroot $(pwd)/fooroot/ filesystem ``` See the output in the attachement.
This bug is an utter disgrace. I'm on fully updated F25. I download the dnf sourcecode from git. I to install build dependencies for dnf i run: dnf builddep dnf.spec No matching package to install: 'python-libcomps >= 0.1.8' etc Latest available pything-libcomps is 0.1.7. I enable Rawhide repository, which contains 0.1.8, and I get this: Last metadata expiration check: 0:09:00 ago on Thu Jul 13 13:14:39 2017. --> Starting dependency resolution --> Finished dependency resolution Dependencies resolved. ======================================================================================================================================================================= Package Arch Version Repository Size ======================================================================================================================================================================= Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): bodhi-client noarch 2.8.1-1.fc27 rawhide 57 k python2-bodhi noarch 2.8.1-1.fc27 rawhide 33 k python2-click noarch 6.7-3.fc26 rawhide 130 k Transaction Summary ======================================================================================================================================================================= Skip 3 Packages Nothing to do. UTTERLY USELESS. Not one shred of information on what the real problem is.
Bug closed nearly a year ago, with fix supposedly in F24 rawhide. On F25 now, F26 almost due, and it's still not fixed. Pathetic.
I came across this bug while investigating but 1545433. TLDR: `dnf install mariadb-server` in a Rawhide (F28) container resolves to community-mysql as a dependency. The resolution completes but there are conflicting files preventing the installation. That should be valid and resolution of that bug will be to sort out the conflicting files, but it got me thinking. How do I make dnf show me why it picked community-mysql instead of mariadb? I believe the requirement it is trying to satisfy is mysql(x86-64); why isn't there an dnf flag to show that in the output?
Thanks Carl for your report. But I think that: 1. What you reported is completely new issue, therefore it should in Buqzilla ( this bugzilla has 75 comment and it means any indirect problem with original issue is difficult to solve). 2. If your transaction failed during rpm-check on file conflict it is not a DNF bug but the problem of packages in transaction that doen't have correctly mentioned conflict in spec files. It is possible that two packages on system has the same files, but they have to have same checksums. The information about checksums is only available after rpm download and only rpm can perform a check. Please if you thing that there is still a problem don't hesitate to open a new bug report with additional data. Thanks a lot.
1. It is, sorry my typo prevented the autolinkification: bug 1545433 2. Right, I know that bug 1545433 is due to packaging errors, not dnf itself. I just brought it up as an example where I would have liked dnf to display more verbose output that indicates why dependencies are chosen. As best I can tell, dnf-2.7.5-8.fc28 still does not have a resolution for this.
Ok Carl, then please provide output that you got, and provide output that you expected. Also simple reproducer for issue could be handy. As I mentioned, I would prefer to open a new issue.
Jaroslav, I opened bug 1549851 as requested. I included examples using dummy packages to demonstrate the core problem. *** This bug has been marked as a duplicate of bug 1549851 ***