Bug 658065

conflicting file is not expected to have the same content on all arches and is generated during the build, so there is no easy nor clean way how to fix this. I'm planning to close this bug as wontfix, any objections?

Michal,
before closing I'd like to better understand the implications of this.

Is that handled differently in RHLE5 or rpm simply ignores the conflict? 

Is config.h supposed to be included in other source files or not? What will happen if the user has installed both packages (32 and 64bit) and tries to build an application that uses config.h ? Will the different content have any impact? 

Can we remove the 32bit package from the tree ?

(In reply to comment #2)
> Michal,
> before closing I'd like to better understand the implications of this.
> 
> Is that handled differently in RHLE5 or rpm simply ignores the conflict? 

differently, we do not ship devel sub-package nor any plugin sub-package

> Is config.h supposed to be included in other source files or not? 

yes 
> What will
> happen if the user has installed both packages (32 and 64bit) and tries to
> build an application that uses config.h ? 

there is no "usual" way how to install both packages (because of that conflict) without forcing it and if user deliberately breaks his system, which you can't prevent him from doing so, it's his fault

> Will the different content have any
> impact? 

yes, it could silently break plugins (struct sizes and other stuff like that))

> Can we remove the 32bit package from the tree ?

you are asking wrong person, from my pov I don't see any reason why both 32bit and 64bit version would be needed nor why 64bit is not sufficient

Adding Dennis to CC. 

Dennis,
can we remove dovecot-devel 32bit?

In RHEL 6, we pull in all -devel packages as multilib by default.  It's possible to add exclusions, but I would like to understand first why this package should be an exclusion.  Is it possible to fix the multilib issue using tips from http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks?

I've looked at it already but did not find anything useful for this situation. It can be solved using wordsize ifdefs, but I have doubts it's really bulletproof and even on that page is written that that kind of api specification is bad. Also I doubt anyone ever tries to compile anything against dovecot-devel, so I don't think using ugly solutions for this is worth it at all.

Based on Michal's opinion, I'm giving dev_nack for that issue... please, add dovecot to multilib exclusion, Dennis.

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Moving to releng and re-opening.

dovecot-devel added to multiarch blacklist in distill and should get removed from the next compose.

# pwd
/mnt/redhat/nightly/RHEL6.1-20110207.n.0/6

# find -name "dovecot-devel*"
./Workstation/optional/i386/os/Packages/dovecot-devel-2.0.9-2.el6.i686.rpm
./Workstation/optional/x86_64/os/Packages/dovecot-devel-2.0.9-2.el6.x86_64.rpm
./Server/optional/i386/os/Packages/dovecot-devel-2.0.9-2.el6.i686.rpm
./Server/optional/x86_64/os/Packages/dovecot-devel-2.0.9-2.el6.x86_64.rpm
./Server/optional/ppc64/os/Packages/dovecot-devel-2.0.9-2.el6.ppc64.rpm
./Server/optional/s390x/os/Packages/dovecot-devel-2.0.9-2.el6.s390x.rpm

No multilib packages for dovecot-devel. Moving to VERIFIED.

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-2011-0540.html