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

[Alejandro Alvarez Ayllon]

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),
which doesn't make much sense, since the 64 bits version of the server 
won't run with the 32 bits
libraries.

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.

globus-gridftp-server-progs is the server, and dpm-dsi is the module.

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?

Regards.

[Rex Dieter]

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),
>  which doesn't make much sense, since the 64 bits version of the server
>  won't run with the 32 bits
>  libraries.
>  
>  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.
>  
>  globus-gridftp-server-progs is the server, and dpm-dsi is the module.
>  
>  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? 
Packages that contain shared libraries are multilib'd (usually).

One "fix" here would be to put the shared libraries into some -libs subpkg 
that either has no dependencies or a non-arch'd dependency on the base pkg 
here.

-- rex

[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

[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.

[Rex Dieter]

Alejandro Alvarez Ayllon wrote:

>  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) 
I'd venture dpm-dsi could drop %{_isa} from this dependency.

-- rex