default _libexecdir is fine for the rpm, "local" is to appear in the convenience symlink's path.
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
(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.
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) ?
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 ***