Understanding multi-lib conflicts in packages

[Michael Schwendt]

On Sat, 10 Feb 2007 18:27:59 -0500, Matthias Clasen wrote:

> > Can %doc files cause a conflict?
> >   
> Yes, this is a common form of multilib conflict,  which often arises when
> documentation is generated at build time and the doc generator (e.g. gtk-doc
> or doxygen) embeds timestamps or some other random data in the generated
> docs.
> 
> The easiest fix here is often to use pregenerated docs as separate source
> instead of generating the docs at build time.

That is a very inconvenient solution, however.

> > I assume include files can cause a conflict.
> >   
> Yes, quite a few libraries install config.h-alike headers which naturally
> cause conflicts.

My mail was phrased poorly. ;) I didn't mean to ask whether include files
can differ between one arch and another. Surely they can. E.g. when they
contain targetarch-dependent definitions, they can be difficult to fix for
multi-lib. I want to ignore conflicting -devel packages as much as
possible, since the -devel packages are optional. Having i386 and x86_64
headers installed in parallel is not a hard requirement. Library packages,
on the contrary, can be pulled in as dependencies of a multi-compat
application or another library. An i386 library (or "main" packages in
general) should not conflict with its x86_64 counter-part because of %doc
files, data files, or config files, for example.

> > I assume arch-independent data files can cause a conflict.
> >   
> Only if they are generated at build time and include timestamps or other
> variable data.

So, when RPM does not play any multi-lib tricks with files below
%_datadir, there are several packages in Extras Devel which conflict
because they contain arch-independent files which have different checksums
on i386 compared with x86_64.