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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
