yum dependency resolution behaviour

Latest response

I have come across a behaviour in yum which I find a little strange when updating a package that has dependencies. I can resolve the issue easily (provide the dependency) but I am interested to know why yum behaves the way it does. Take the following example:

[root@rhel65 ~]# rpm -qa | grep iptables
iptables-1.4.7-11.el6.x86_64
iptables-ipv6-1.4.7-11.el6.x86_64


[root@rhel65 ~]# yum update iptables-1.4.7-14.el6.x86_64.rpm
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Setting up Install Process
Examining iptables-1.4.7-14.el6.x86_64.rpm: iptables-1.4.7-14.el6.x86_64
Marking iptables-1.4.7-14.el6.x86_64.rpm as an update to iptables-1.4.7-11.el6.x86_64
Resolving Dependencies
--> Running transaction check
---> Package iptables.x86_64 0:1.4.7-11.el6 will be updated
--> Processing Dependency: iptables = 1.4.7-11.el6 for package: iptables-ipv6-1.4.7-11.el6.x86_64
---> Package iptables.x86_64 0:1.4.7-14.el6 will be an update
--> Running transaction check
---> Package iptables.i686 0:1.4.7-11.el6 will be installed
--> Processing Dependency: libm.so.6 for package: iptables-1.4.7-11.el6.i686
--> Processing Dependency: libdl.so.2(GLIBC_2.1) for package: iptables-1.4.7-11.el6.i686
--> Processing Dependency: libdl.so.2(GLIBC_2.0) for package: iptables-1.4.7-11.el6.i686
--> Processing Dependency: libdl.so.2 for package: iptables-1.4.7-11.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.7) for package: iptables-1.4.7-11.el6.i686
--> Running transaction check
---> Package glibc.i686 0:2.12-1.132.el6 will be installed
--> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.12-1.132.el6.i686
--> Processing Dependency: libfreebl3.so for package: glibc-2.12-1.132.el6.i686
--> Running transaction check
---> Package nss-softokn-freebl.i686 0:3.14.3-9.el6 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 iptables which is missing some
            dependency that another package requires. Yum is trying to
            solve this by installing an older version of iptables 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 iptables.otherarch ... this should give you an error
            message showing the root cause of the problem.

         2. You have multiple architectures of iptables installed, but
            yum can only see an upgrade for one of those arcitectures.
            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 iptables 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: iptables-1.4.7-14.el6.x86_64 != iptables-1.4.7-11.el6.i686
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

The iptables-ipv6 package depends on the iptables package. In this example, I intentionally attempt to upgrade only the iptables package (which I would expect to fail), but the part that intrigues me is how yum fails. Because the upgrade is increasing the iptables package version, yum then attempts to resolve the iptables-ipv6 package dependency using the equivalent versioned iptables.i686 package which then leads it down a path of continued dependency solving.

It correctly explains the situation in suggestion '1.' of the error, but my questions are:

Would the i686 version of the package really solve the dependency for iptables-ipv6.x86_64? why does yum even attempt that? The iptables.i686 provides 'iptables' which iptables-ipv6 is looking for, but the configuration will result in iptables-ipv6.x86_64 and iptables.i686 at the same version being apparently OK for dependency requirements? (ignoring the upgraded iptables.x86_64).

The behaviour I expected was for yum to complain that iptables-ipv6 depends on iptables (without the resulting i686 package treasure hunt), which is exactly how native RPM handles it:

[root@rhel65 ~]# rpm -Uvh iptables-1.4.7-14.el6.x86_64.rpm
warning: iptables-1.4.7-14.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
error: Failed dependencies:
    iptables = 1.4.7-11.el6 is needed by (installed) iptables-ipv6-1.4.7-11.el6.x86_64

Why are they handled differently?

Responses

Hi,

This is a longstanding issue, and I'm afraid there are no plans to address it even in Fedora. See https://bugzilla.redhat.com/show_bug.cgi?id=543963#c18 and below.

Radek

That's really disappointing if true. Is there any suggestion that this behaviour would be desirable in certain situations?

I have been bitten by this now with both iptables and xz / xz-libs..

Desirable? No, I don't think so. Yum can't really use the older version of the compat-arch package to satisfy the dep AND still try to update the native-arch package. It's a bug.

Sorry to harp on with this one, but I don't follow why it's not being addressed. It's been determined it's a bug, there appears to be no reason to maintain the current behaviour, but Red Hat don't plan to fix it?

Are there concerns about regression if fixed? Surely there is a valid reason why they are not planning to fix it? Is there any more information on this decision other than the associated bugzilla above?

If a paying Red Hat Support customer raises this as a support issue, what is the likely response?

PixelDrift,

Working on the bug https://bugzilla.redhat.com/show_bug.cgi?id=543963#c18 can only be triggered a customer who has the same issue, for like every bugzilla one needs to be able to give a report on how it happened.

Kind regards,

Jan Gerrit

Hi Jan,

Apologies, I don't completely follow your post.

It appears this has been raised as an 'RFE', but this isn't really an enhancement, it's a bug, it also appears that no changes have been made to the issue since March 2012 (3 years ago).

I think the bug is easy enough to replicate (I have provided steps above to do this), but I will add my details above to the bugzilla to hopefully bring some focus back to it.

My question really was, if a customer with paid support raises this as it is a genuine bug, will Red Hat champion for it to be resolved in upstream? or just respond with 'wontfix'?

If the former, I will raise it through official support channels over adding it directly to bugzilla.

-edit-

I raised it directly in the bugzilla link provided for now, thanks for providing the link Radek / Jan.

PixelDrift,

Whether Red Hat would jump on it or leaved it as unable to fix, we cannot answer. That is up to Red Hat support to decide.
Did you try:

yum update iptables iptables-ipv6

What you try to here is something rpm also has trouble with updating a rpm in the middle of a dependency chain.

iptables is needed by iptables-ipv6.

A feature enhancement, like suggesting which rpms should be updated to "repair" the chain would be great.

Instead of this message: multilib version issue.

Kind regards,

Jan Gerrit

Jan,

I am not after a resolution to the iptables issue, the above example is completely contrived and easily resolved (by removing the ipv6 package which requires iptables, or including the newer ipv6 x86_64 package in the yum update).

I am using the above example to focus attention to the bug in the way yum attempts to resolve an x86_64 dependency with an i686 package, this was the simplest way to represent the undesirable behaviour.

Thanks for commenting on the bug. I hope someone from Engineering replies. Could you please also go ahead and contact Red Hat Support? They should make sure the issue is tracked for RHEL 6 and prioritized appropriately.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.