Bug 764679 - (GLUSTER-2947) do not tamper with libexecdir in rpm spec
do not tamper with libexecdir in rpm spec
Status: CLOSED DUPLICATE of bug 764702
Product: GlusterFS
Classification: Community
Component: scripts (Show other bugs)
mainline
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Amar Tumballi
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-26 02:39 EDT by Csaba Henk
Modified: 2013-12-18 19:06 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-18 07:00:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Csaba Henk 2011-05-26 02:39:19 EDT
default _libexecdir  is fine for the rpm, "local" is to appear in the convenience symlink's path.
Comment 1 Amar Tumballi 2011-10-25 00:06:50 EDT
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 10:03:42 EDT
(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 15:11:51 EDT
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 07:00:17 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.