On Tue, 26 Jan 2010, Panu Matilainen wrote:
On Mon, 25 Jan 2010, Richard W.M. Jones wrote:
> On Mon, Jan 25, 2010 at 02:08:10PM -0500, Bill Nottingham wrote:
>> - If the file in both packages is identical, installation is allowed
>> and the file is written
>> - If the file in both packages is an ELF binary, the file used is the
>> file in the package for the primary architecture
>> - If the file in both packages is not an ELF binary a RPM conflict is
>> raised
>
> Are you sure about the third rule?
Yes.
> I think the problem arises because /usr/bin/libguestfs-supermin-helper
> is different in libguestfs.i686 and libguestfs.x86_64, but this file
> is a shell script, not an ELF binary.
>
> These are the files in libguestfs.i686 and libguestfs.x86_64 that have
> the same names but different content:
>
> /usr/bin/hivexget (ELF binary)
> /usr/bin/hivexml (ELF binary)
> /usr/bin/libguestfs-test-tool (ELF binary)
> /usr/libexec/libguestfs-test-tool-helper (ELF binary)
> /usr/bin/libguestfs-supermin-helper (shell script)
>
> Anyway, I will move the shell script and see if that helps.
Wont help, the multilib file "shadowing" logic is NOT based on paths.
Looking at libguestfs.spec, here's the problem:
%global _use_internal_dependency_generator 0
The external dependency generator doesn't create the file "coloring" that
the multilib magic needs to operate. So you'll get conflicts on all paths
where content differs.
...except looking at libguestfs-1.0.75-1.fc12, it *has* been built with
internal dependency generator, and it gives:
Preparing... ###########################################
[100%]
file /usr/bin/libguestfs-supermin-helper conflicts between
attempted installs of libguestfs-1:1.0.75-1.fc12.i686 and
libguestfs-1:1.0.75-1.fc12.x86_64
...which is the expected behavior for a non-elf file (script in this case
but doesn't matter). If both arch's of libguestfs have been installed,
--replacefiles or --force has been used to force the install despite
of a conflicting file.
- Panu -