Avoid a 32 bits package from being pushed into 64 bits repository

[Michael Schwendt]

On Tue, 30 Apr 2013 12:47:24 +0200, Alejandro Alvarez Ayllon wrote:

> Hello,
> 
> I co-maintain a package that contains a library that is used as module 
> for a server.
> The 32 bits version of this library is pushed automatically into the 64 
> bits repositories (i.e. in epel6),

That's because of the multilib compose strategy, which allows for [either]
building or running 32-bit software with 64-bit installations and added
32-bit system libs. One basic strategy is to add to the target repo the
arch-compatible -devel packages and their base package dependencies.

> which doesn't make much sense, since the 64 bits version of the server 
> won't run with the 32 bits libraries.

?? The 64-bit version of the server depends on the 64-bit libs, doesn't it?
Some details about the problem are missing here.
 
> This wouldn't be a big problem, but the pushed 32 bits rpm has a dependency
> on the 32 bits server, so then I will get complains (with reason) about 
> the broken package.

What exactly is the error? Is it caused by automatic dependencies or
by manually added (or missing) %_isa dependencies?
 
> globus-gridftp-server-progs is the server, and dpm-dsi is the module.

"globus-gridftp-server" is the base %name in case anyone searches for it.

The dpm-dsi packaging is a bit questionable, because it creates a separate
-devel package for only two tiny C header files. The base package contains
a *.so plug-in lib. One could have included the two headers in the base
package (with a virtual -devel package). The two headers include other
headers which are missing. A missing Requires on another -devel package?

[Note that I haven't checked what sort of API these two headers define and
how it relates to the plug-in lib in the base package. Sometimes plug-in
authors publish a private/internal interface, and for a long time -- or
forever ;) -- nothing uses it.]

> So my question is: how should I approach this? I got some suggestions in 
> this ticket
> https://bugzilla.redhat.com/show_bug.cgi?id=957588
> 
> Is there any way I can prevent this rpm from being copied into the 64 
> bits repositories?

Typically, I can comment on dependency problems (including multilib related
ones) provided that I know the exact scenario. That is either a detailed
broken deps report or a yum update scenario. I've not found such details.

-- 
Michael Schwendt
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc8.git0.2.fc19.x86_64
loadavg: 0.03 0.12 0.21