Mailing List ArchivesAuthenticated access |
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesAuthenticated access |
|
|
Hi, I’m getting condor from the « official repositories », and yum tells me there’s an issue with apparently condor 8.* . I did not face this at first because I setup htcondor on already installed machines, but for instance for a VOMS library : On a typical worker : # rpm -q voms voms-2.0.11-2.el6.x86_64 voms-2.0.11-2.el6.i686 If we install that machine from scratch, yum will choose to install both the i686 and x86_64 version of htcondor in place of the voms rpms. But the voms RPMs are multiarch compatible, and not condor… I see the puppet module I used to install/configure htcondor excluded the condor.i386 rpm, I guess I’ll have to add .i686 too but that remains a workaround. # yum -C whatprovides libvomsapi.so.1 Loaded plugins: priorities, protectbase, security 0 packages excluded due to repository protections condor-8.2.1-256063.i686 : Condor: High Throughput Computing Repo : htcondor-stable Matched from: Other : libvomsapi.so.1 condor-8.2.0-254849.i686 : Condor: High Throughput Computing Repo : htcondor-stable Matched from: Other : libvomsapi.so.1 voms-2.0.11-2.el6.i686 : Virtual Organization Membership Service Repo : irfu-epel Matched from: Other : libvomsapi.so.1 voms-2.0.10-1.el6.i386 : The Virtual Organisation Membership Service C++ APIs Repo : irfu-emi3-base Matched from: Other : libvomsapi.so.1 condor-8.0.7-250355.i686 : Condor: High Throughput Computing Repo : htcondor-stable Matched from: Other : libvomsapi.so.1 voms-2.0.11-1.el6.i686 : The Virtual Organisation Membership Service C++ APIs Repo : irfu-emi3-updates Matched from: Other : libvomsapi.so.1 voms-2.0.11-2.el6.i686 : Virtual Organization Membership Service Repo : installed Matched from: Other : Provides-match: libvomsapi.so.1 ð
Yum will always choose htcondor. :’( Regards De : HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx]
De la part de Steven C Timm Frederic--which version of the htcondor rpms are you using and From: HTCondor-users [htcondor-users-bounces@xxxxxxxxxxx]
on behalf of 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… |