Bug 970211 - dnf attempts to use old library
dnf attempts to use old library
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: libsolv (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-03 13:20 EDT by Karl Campbell
Modified: 2013-06-26 02:42 EDT (History)
6 users (show)

See Also:
Fixed In Version: libsolv-0.3.0-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-26 02:42:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
command output (30.61 KB, text/plain)
2013-06-03 13:20 EDT, Karl Campbell
no flags Details
Disable colored obsoletes in hawkey (781 bytes, patch)
2013-06-04 03:55 EDT, Panu Matilainen
no flags Details | Diff

  None (edit)
Description Karl Campbell 2013-06-03 13:20:57 EDT
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.
Comment 1 Ales Kozumplik 2013-06-03 15:35:29 EDT
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.
Comment 2 Panu Matilainen 2013-06-04 03:31:14 EDT
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.
Comment 3 Panu Matilainen 2013-06-04 03:55:23 EDT
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]#
Comment 4 Michael Schröder 2013-06-04 07:00:58 EDT
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?
Comment 5 Michael Schröder 2013-06-04 07:20:56 EDT
(Commit #ee3a248c in libsolv should fix this issue)
Comment 6 Panu Matilainen 2013-06-04 08:53:15 EDT
(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...
Comment 7 Ales Kozumplik 2013-06-26 02:42:45 EDT
closing per comment 6, ee3a248c51e0189eeacafaf3a27fc1571af04253 is included in the latest F19 build of libsolv.

Note You need to log in before you can comment on or make changes to this bug.