[HTCondor-users] htcondor globus libraries causing RPM conflicts

[SCHAER Frederic <frederic.schaer@xxxxxx>]

Hi,

 

I am trying a clean install of an EMI/UMD worker node, with condor, and I faced unexpected issues :

 

The EMI emi-wn meta-package installs a bunch of RPMs, amongst which i686 ones, which themselves request install of i686 libs, and so on and so on.

But when it comes to globus libraries, htcondor wins the transaction because (I think) it provides many deps in a single dependency, thus defeating multiple packages in epel and EMI repos which only contain one dep per package (the least packages are installed, the best the rpm is in the yum matchmaking).

 

Then, this is causing the fatal issue when yum attempts to install both htcondor x86_64 and i686 at the same time, because of the multiarch libs deps...

 

Tell me if I’m wrong, but I’m assuming that relying on condor-shipped globus libraries would also cause other issues for non-condor globus enabled packages since those libs are under /usr/lib64/condor and thus unknown to the standard LD_LIBRARY_PATH, as opposed to the globus libs which live under /usr/lib and /usr/lib64… ?

 

Using the yum-priorities plugin is impossible because the new htcondor packages are way more recent than what’s available in epel or EMI/UMD, and thus either I would have an emi-wn with an old condor, or a new condor without an emi-wn.

I’m therefore wondering if there wouldn’t be an issue in the way condor is packaged ?

Can’t it be possible to ship it with separate library packages (that could be installed on multiarch systems), and is this expected to conflict with globus packages ?

 

Thanks

 

P.S : I know I can work that arouns with yum install –exclude condor emi-wn, and I’ll use that for now…