Description of problem: Installing i386 packages on ia64 causes file conflict for tcp_wrappers Preparing... ################################################## file /usr/lib/libwrap.a from install of tcp_wrappers-7.6-37.6.el4 conflicts with file from package tcp_wrappers-7.6-37.6.el4 Version-Release number of selected component (if applicable): tcp_wrappers-7.6-37.6.el4/RHEL4.8 snap #1 How reproducible: Always/ia64
Panu, is this something to do with updated rpm version?
Scratch comment #2. tcp_wrappers did changed: tcp_wrappers-7.6-37.4.i386.rpm -> tcp_wrappers-7.6-37.6.el4.i386.rpm
This seems to be bug in RPM itself, I can't find anything wrong with the .spec file and generated package.
Panu, is this an issue with rpm?
Investigation so far: RPM thinks, that /usr/lib/ does *not* need to be relocated to /emul/ia32-linux/whatever. The directory contains libwrap.a and symlink libwrap.so -> ../../lib/libwrap.so.0.7.6. The reason is, that neither libwrap.a nor libwrap.so has the right 'color', see lib/rpmfi.c:936 - color of the files is being copied to color of directories and the /var/lib/ directory ends with no color. Only 'colored' directories are relocated (i.e. directories containing colored files). RPM read color of files from RPM header, i.e. rpmbuild created rpm file with wrong (?) colors.
rpmbuild correctly guess .a file colors (RPMFC_STATIC|RPMFC_LIBRARY|RPMFC_ARCHIVE|RPMFC_INCLUDE), but on build/rpmfc.c:1578 all the colors are cleared and only few pass to outgoing RPM file header: /* XXX Make sure only primary (i.e. Elf32/Elf64) colors are added. */ for (i = 0; i < c; i++) fcolors[i] &= 0x0f; Maybe the RPMFC_LIBRARY color should survive... Libraries (either static or shared objects) should be always relocated to the right directory.
Both static and dynamic libraries are in /lib now.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1032.html