Created attachment 756425 [details] command output Description of problem: When attempting to install Steam from the steam repo, dnf attempts to install mesa-dri-filesystem.i686.9.0.1-1.fc18. However, this version is obsoleted by the currently installed version (mesa-filesystem.i686 0:9.2-0.7.20130528.fc18) "yum install steam" worksm where "dnf install steam" does not. command line output in attachments. Version-Release number of selected component (if applicable): dnf --version 0.2.23 Installed: dnf-0:0.2.23-1.git50db212.fc18.noarch at 2013-06-03 16:29 Built : Fedora Project at 2013-03-21 12:43 Installed: rpm-0:4.10.3.1-1.fc18.x86_64 at 2013-02-16 18:11 Built : Fedora Project at 2013-02-06 09:54 How reproducible: On a fully updated Fedora 18 system, attempt to install Steam using dnf. Steps to Reproduce: 1. 2. 3. Actual results: Installation fails using dnf, whereas using yum works. Expected results: yum and dnf should produce the same results. Additional info: I am using a x86_64 system, but the packages to be installed are i686.
Thanks for the report, you are witnessing someting odd (perhaps a mismatch between libsolv and the RPM behavior described in bug 840613). Unfortunately this is hard to debug with the 0.2.23 DNF version. Once you move to F19, can you please try with a more recent version of DNF. If you see the same error, please rerun with: dnf --debugsolver install steam and attach the created ./debugdata directory.
I was able to reproduce this with 'dnf install mesa-dri-drivers.i686', and its indeed related to bug 840613. From debugdata/testcase.t: poolflags obsoleteusescolors That's the rpm < 4.10 behavior, for the newer versions we need this someplace (in hawkey I guess): pool_set_flag(pool, POOL_FLAG_OBSOLETEUSESCOLORS, 0); Tested this with the 'solv' demo client and with obsoletion colors disabled, libsolv figures there's a problem: --- Found 1 problems: Problem 1/1: installed package mesa-filesystem-9.2-0.7.20130528.fc18.x86_64 obsoletes mesa-dri-filesystem < 9.2-0.7.20130528.fc18 provided by mesa-dri-filesystem-9.0.1-1.fc18.i686 Solution 1: - allow deinstallation of mesa-filesystem-9.2-0.7.20130528.fc18.x86_64 - allow deinstallation of mesa-dri-drivers-9.2-0.7.20130528.fc18.x86_64 Solution 2: - do not ask to install mesa-dri-filesystem.i686 --- Apart from that, the issue presumably comes from yum/dnf happening to use different mirrors with dnf looking at a mirror which doesn't yet have the newer mesa version which was installed with yum from another mirror. There are also at least two different (trivial) trackebacker bugs in the dnf error reporting when "ERROR with transaction check vs depsolve" occurs, patches for those to follow.
Created attachment 756649 [details] Disable colored obsoletes in hawkey The attached patch to hawkey fixes this: [root@localhost dnf]# LD_LIBRARY_PATH=/tmp/htest/usr/local/lib64/ bin/dnf install mesa-dri-drivers.i686 Setting up Install Process Resolving Dependencies --> Starting dependency resolution --> Finished dependency resolution Error: package mesa-dri-drivers-9.0.1-1.fc18.i686 requires libdrm.so.2, but none of the providers can be installed [root@localhost dnf]#
Argh, Fedora multilib is driving me insane ;) I'll split the "obsoleteusescolors" flag into two flags, like with obsoleteusesprovides. Simply disabling it doesn't work, because it makes it impossible to install a package in two architectures. Switching the topic: I still need some "oracle function" so that the solver knows if a package is a multilib package or not. Currently the "infarch" rules are made weak (i.e. breakable) if obsoleteusescolors is set, but we want hard for non-multilib package. I.e. we want to ask the user for permission before installing the i586 version of an application when there is a x86_64 version. The oracle function I have in mind would check the filelist from the primary.xml of the package, if there are entries in /bin, /usr/bin, or /etc it can't be a multilib package. Does that make sense?
(Commit #ee3a248c in libsolv should fix this issue)
(In reply to Michael Schröder from comment #4) > Argh, Fedora multilib is driving me insane ;) Heh, you're not alone in that... > I'll split the "obsoleteusescolors" flag into two flags, like with > obsoleteusesprovides. Simply disabling it doesn't work, because it makes it > impossible to install a package in two architectures. Right, I'm obviously not sufficiently familiar with libsolv flags and internals yet :) Anyway, commit #ee3a248c in libsolv seems to fix, thanks. > Switching the topic: > > I still need some "oracle function" so that the solver knows if a package is > a multilib package or not. Currently the "infarch" rules are made weak (i.e. > breakable) if obsoleteusescolors is set, but we want hard for non-multilib > package. I.e. we want to ask the user for permission before installing the > i586 version of an application when there is a x86_64 version. > > The oracle function I have in mind would check the filelist from the > primary.xml of the package, if there are entries in /bin, /usr/bin, or /etc > it can't be a multilib package. Does that make sense? That wont work because multilib packages can and do have entries in those paths, and that's where the rpm-side coloring really steps into the picture. Knowing whether a package is a multilib-one or not is pretty much a mission impossible, as this can change between updates and all: a package might start its life as non-multilib but then grow a multilib-variant along updates, or the other way around. When you add partially out-of-sync repositories and all to the picture...
closing per comment 6, ee3a248c51e0189eeacafaf3a27fc1571af04253 is included in the latest F19 build of libsolv.