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.
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
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.
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.
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
-
Alejandro Alvarez Ayllon -
Michael Schwendt -
Rex Dieter