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

[Alejandro Alvarez Ayllon]

Hi,

On 01/05/13 12:24, Michael Schwendt wrote:
> 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.

What I want to say is that there is no 32 bits server, so a 32 bits 
plug-in will be useless.
The server does _not_ depend on our plugin. Our plug-in depends on the 
server.

>   
>> 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?
Manually added %_isa
>> 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.]
Now you mention it, I am checking with the developer what's the 
potential use case for those headers,
as they seem internal to me. If there is none, I'll remove the -devel. 
If there is,
I'll add the missing deps.

>
>> 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.
>
The "Broken dependencies" report I have been getting for a while now:

dpm-dsi has broken dependencies in the epel-6 tree: On x86_64: 
dpm-dsi-1.9.0-2.el6.i686 requires globus-gridftp-server-progs(x86-32) 
Please resolve this as soon as possible.

Cheers.