Bug 764679 (GLUSTER-2947)

Summary: do not tamper with libexecdir in rpm spec
Product: [Community] GlusterFS Reporter: Csaba Henk <csaba>
Component: scriptsAssignee: Amar Tumballi <amarts>
Status: CLOSED DUPLICATE QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: mainlineCC: gluster-bugs, kbudiger, vbellur, vraman
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-18 11:00:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Csaba Henk 2011-05-26 06:39:19 UTC
default _libexecdir  is fine for the rpm, "local" is to appear in the convenience symlink's path.

Comment 1 Amar Tumballi 2011-10-25 04:06:50 UTC
Csaba,

Any thoughts on how to fix this? I saw that in glusterfs.spec, /usr/local is still present to get the libexec dir.

Regards,
Amar

Comment 2 Csaba Henk 2011-10-25 14:03:42 UTC
(In reply to comment #1)
> Csaba,
> 
> Any thoughts on how to fix this? I saw that in glusterfs.spec, /usr/local is
> still present to get the libexec dir.
> 
> Regards,
> Amar

My point was that the 

%define _libexecdir %{_prefix}/local/libexec/

definition is not necessary, as the rpm environment defines _libexecdir and we can use that value.

I made this claim by looking at rpm settings but have not verified in practice; therefore I asked Lakshmi to check if this claim is truem, and if yes, submit a patch for dropping the def. He did not do this during his tenure.

Other somewhat dubious practice is that we install a symlink at /usr/local/libexec/glusterfs/gsyncd pointing to the install-path of gsyncd (/usr/libexec/glusterfs/gsyncd as of default?). This is done in order to ensure geo-rep works with the default configuration (bridging thus a lame difference regarding defaults: autotools' default $PREFIX is /usr/local, while most linux packaging systems install to /usr by default). If we keep this compat symlink, that definitely implies a hard-wired /usr/local/... path in the RPM spec. While this hack has no place in my heart, I'm OK with it as a necessary workaround.

NB, the suggested setup for geo-rep in 3.3 will not rely on this hack anymore, as in that scenario it's up to slave to specify where its gsyncd executable is located.

Comment 3 Amar Tumballi 2012-04-17 19:11:51 UTC
Csaba,

Do you think this bug will hold fine for 3.3.x branch onwards? if not can I close it with WONTFIX (or whatever is appropriate) ?

Comment 4 Csaba Henk 2012-04-18 11:00:17 UTC
Amar, this issue (and much more) is already taken care of in http://review.gluster.com/701 -- hence we can just mark it as duplicate of the corresponding bug, #764702

*** This bug has been marked as a duplicate of bug 764702 ***