Created attachment 944684 [details] Fix for early return with autoreqprov disabled Description of problem: When we use AutoReqProv (or both AutoReq/AutoProv) set to "no", it cause conflict problems during installation of ELF binary files in multilib environments. Version-Release number of selected component: 4.11.3-1 How reproducible: Steps to Reproduce: 1. Build any multilib package with ELF binaries with "AutoReqProv: no" for x86 and x86_64 arch. 2. Install both x32 and x64 rpm with yum or rpm 3. Get error about conflicting files Actual results: Installation failed. Conflicts between x32 ELF binary and x64 occurred Expected results: Installation succeeded. When a conflict is found between x64 and x32 packages, the installed file is the one from the preferred arch - x64. Additional info: This is because "AutoReqProv: no" turns off additional file attributes processing, in particular, ELF coloring. But when we use this macros is expected to handle just requires/provides. Note: using AutoReq or AutoProv singly are not causing such problem. Proposed patch: Disabling early checking for disabled pkg->autoReq and pkg->autoProv can fix the problem. But I am not sure is that a right way to fix it or can broke any other rpm logic.
The patch is not correct, but yes file coloring required for the multilib file conflict resolution magic is tied to dependency generation with internal dependency generator. Using the legacy external dependency generator has the same effect. So yeah it is a bug, file coloring should occur independently of dependency generation because logically they have nothing to do with each other. In the meanwhile, the issue can be avoided by either a) split the package in a way that avoids such file conflicts in the first place b) filtering dependencies out instead of AutoReqProv, see http://rpm.org/wiki/PackagerDocs/DependencyGenerator#TweakingDependencyGenerators
After fixing it a bit differently upstream I realized the patch was correct afterall, autoReq/autoProv are necessarily handled independently elsewhere already. Oh well :) Anyway, this covers more ground by introducing coloring to packages generated with external dependency generator as well, which has been an increasingly common source of problems: http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=05636a7db213e8255d6893c638a80d52390c3527 Thanks for the report and the patch!