yum dependency resolution behaviour
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