Description of problem: librdkafka in EPEL7 violates the EPEL policy because it provides the same package as RHEL7, but only strikt x86_64 whereas RHEL7 provides x86_64 and i686 Version-Release number of selected component (if applicable): EPEL librdkafka-0.11.5-1 RHEL librdkafka-0.11.4-1.el7 How reproducible: Add and enable EPEL7 and try to install librdkafka.i686 librdkafka.x86_64 librdkafka-devel.i686 librdkafka-devel.x86_64 Steps to Reproduce: 1. add and enable epel7 like describe in EPEL Homepage 2. yum install librdkafka.i686 librdkafka.x86_64 librdkafka-devel.i686 librdkafka-devel.x86_64 Actual results: yum multilib error: Resolving Dependencies --> Running transaction check ---> Package librdkafka.i686 0:0.11.4-1.el7 will be installed ---> Package librdkafka.x86_64 0:0.11.5-1.el7 will be installed ---> Package librdkafka-devel.i686 0:0.11.4-1.el7 will be installed ---> Package librdkafka-devel.x86_64 0:0.11.5-1.el7 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 librdkafka-devel which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of librdkafka-devel 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 librdkafka-devel.otherarch ... this should give you an error message showing the root cause of the problem. 2. You have multiple architectures of librdkafka-devel 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 librdkafka-devel 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: librdkafka-devel-0.11.5-1.el7.x86_64 != librdkafka-devel-0.11.4-1.el7.i686 Error: Protected multilib versions: librdkafka-0.11.4-1.el7.i686 != librdkafka-0.11.5-1.el7.x86_64 Expected results: have all 4 packages installed in consistent version Additional info: This could be worked around by disabling EPEL
I am not sure what the ideal solution would look like. Do we need to retire the package from EPEL repo?
I know complex, especially at this point of the RHEL7 lifecycle. From a EPEL policy point it is pretty clear (at least from my naive point of view) -> retire. But I guess the requester didn't roll the package just for fun and likely he (and we?) would like to see the .5 changes/enhancement in RHEL7 anyway (not likely to happen - and I didn't look into details what actually changed). Is providing the complete consistent set librdkafka{,-devel}.{x86_64,i686} from EPEL an option? The mixture is actually why we noticed it at all - and yes we're currently on i686 and x86_64 (working towards 64bit only on RHEL8)
I followed the Fedora/EPEL package removal guide and retired librdkafka from EPEL7 with the following steps [1]: - executed fedpkg retire "Remove librdkafka from EPEL 7, as it is available in RHEL-7, otherwise package violates EPEL policy." - check if the package is listed in the comps. it's not listed there. - check if the package is part of the spin kickstart file. it's not listed there. - to keep retired packages from being pushed to the mirrors, they need to be blocked in Koji. This is not done yet. Will need to wait for automation to kick in. [1] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#epel::epel-policy-retirement.adoc/ [2] https://src.fedoraproject.org/rpms/librdkafka/tree/epel7