Understanding multi-lib conflicts in packages

[Michael Schwendt]

On Wed, 14 Feb 2007 08:29:13 +0000, Paul Howarth wrote:

> On Tue, 2007-02-13 at 22:27 -0600, Jima wrote:
> > On Tue, 13 Feb 2007, Curtis Doty wrote:
> > > 8:16pm Michael Schwendt said:
> > >> Meanwhile, all automatically found multi-lib conflicts have been reported
> > >> in bugzilla. Only six in Core, 4-5 dozen in Extras (-> FE7Target tracker).
> > >
> > > URL or help please. For those of us who wish to contribute, but don't
> > > already have an advanced degree in the slow and morose beast known as Red
> > > Hat Bugzilla. :-/
> > 
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE7Target
> > 
> >   Not sure which blocking bugs are the multilib conflicts, though.
> 
> Try the dependency tree view instead, which lists the summaries:
> 
> https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE7Target
> 
> Paul.

Interesting are the cases where -devel packages (sometimes tiny ones
for plug-in APIs) cause main 32-bit application packages to be pulled
into the x86_64 repo, which then conflicts in data files (in a few cases
due to packaging bugs). Splitting off a -libs package (for the
corresponding files in the -devel package) should be possible
in most cases, especially since we don't really want 32-bit applications
in the 64-bit repo. As a last resort, there's still the multi-lib blacklist.

... and the additional Core tickets are these:

228311 (FIXED)
228315
228317
228318
228320 (FIXED)
228321 (MODIFIED via Merge review)