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