Description of problem: globus-gridftp-server-progs(x86-32) is missing in epel-6 x86_64 repository since the last upgrade of globus-gridftp-server. This is a dependency of, at least, dpm-dsi.i686, dependency that has been broken when that upgrade was pushed to stable. Version-Release number of selected component: 6.19-1.el6
The globus-gridftp-server-progs package does not contain any libraries and is threfore not intended to be multilib, i.e. that the 32 bit version is not in the 64 bit repo is in line with how multilib in Fedora and EPEL is designed. This in not something that happened on the last update, it was always like that and it was always intended to be like that. To satisfy the undefined symbols in the installed plugin, the symbols in libglobus_gridftp_server are sufficient, so to this end a requirement on globus-gridftp-server(x86-32) is enough (or better, properly link the installed plugin to the libglobus_gridftp_server library to avoid undefined symbols, and this requirement will be handled automatically by rpm). The dependency on the globus-gridftp-server binary seems to come from the start-up script and not from the intalled plugin itself. There are several possible ways to reolve this. 1) Change the requirement on globus-gridftp-server%{?_isa} to globus-gridftp-server. This will resolve the issues with the repo closure, but would make it possible to install the 32 bit plugin only together with a 64 bit server which will not work. (Such an installation would still allow the plugin to be loaded in a 32 bit user application using the 32 bit libglobus_gridftp_server library.) This would be similar to the situation on EPEL 5 where %{?_isa} is empty. 2) Keep the requirement on globus-gridftp-server%{?_isa}, but request that releng blocks the dpm-dsi package from multilib, so that the 32 bit plugin is not available in the 64 bit repo. This will also resole the repo closure problem. This way it will not be possible to install the 32 bit plugin on 64 bit, so the problem with the previous solution will not happen. However, if someone wants to load the plugin in a user 32 bit application it will not be available - this is not a very likely scenario I admit. 3. Split the package, so that the plugin and the start-up scripts are in different packages. The package with the plugin (which does not depend on globus-gridftp-server-progs) would then be multilib while the package with the startup script (which would depend on globus-gridftp-server-progs) would not. This might be the cleanest solution, but is probably an overkill. 4. Something else I did not think about.
Hi, Sorry if that has always been the case. I started getting the error some weeks ago, but it it also true I took over the package not much longer before. I will discuss with upstream if they have any preference on this. Thanks.