[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] htcondor globus libraries causing RPM conflicts



Many thanks :]

Actually, I can confirm the « yum workaround » works in a puppet “exec”

 

Regards

 

De : HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx] De la part de Tim Theisen
Envoyé : jeudi 10 juillet 2014 15:44
À : HTCondor-Users Mail List
Objet : Re: [HTCondor-users] htcondor globus libraries causing RPM conflicts

 

Hi,

The problem with the RPMs from the our official build is that is basically a repackaging of our tarball installation and including the globus and vomsapi libraries. I am currently working on repackaging the HTCondor RPMs leveraging work contributed by the OSG Software team. As soon as it is ready, we will release an 8.2.2 version where HTCondor will install cleanly on your system.

...Tim

On 07/10/2014 02:55 AM, SCHAER Frederic wrote:

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
Envoyé : mercredi 9 juillet 2014 19:15
À : HTCondor-Users Mail List
Objet : Re: [HTCondor-users] htcondor globus libraries causing RPM conflicts

 

Frederic--which version of the htcondor rpms are you using and
where are you getting it from?  It makes  a difference. 

Steve Timm


From: HTCondor-users [htcondor-users-bounces@xxxxxxxxxxx] on behalf of SCHAER Frederic [frederic.schaer@xxxxxx]
Sent: Wednesday, July 09, 2014 12:08 PM
To: htcondor-users@xxxxxxxxxxx
Subject: [HTCondor-users] htcondor globus libraries causing RPM conflicts

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…




_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
 
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/



-- 
Tim Theisen
Release Manager
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736