GNOME Bugzilla – Bug 510917
install ggz demons in libexecdir, not bindir
Last modified: 2012-01-31 23:27:52 UTC
E.g. gnibbles has: bin_PROGRAMS += gnibblesd however these programmes aren't user runnable, so they shouldn't pollute the bindir but instead live in libexecdir.
Created attachment 103339 [details] [review] patch
I'll check if it is a problem for ggzd that the server executables are located in libexecdir. Josef?
Most GGZ game servers are not in ${bindir} unless they are intended to be started by hand, e.g. if they provide a control shell like civserver, or if they run standalone as a daemon (but then they go to ${sbindir} like e.g. the TEG server). So the patch is mostly correct. But it can be improved: When using ggz.m4, there is the special variable ${ggzdexecmoddir} instead of ${libexecdir}. When installing game servers there, the path in ExecutablePath is also not needed anymore, as this directory will be searched by default. Hence, saying ExecutablePath = gnibblesd will suffice.
Created attachment 103366 [details] [review] updated patch: use ggzexecmoddir I'm still putting the whole path into the .dsc files though just to be safe. However: ggzexecmoddir contains ${prefix} instead of ${exec_prefix}; that's a bug in ggz.
Patch applied to SVN: http://svn.gnome.org/viewvc/gnome-games?view=revision&revision=7281
Christian, You are right about ggzexecmoddir containing ${prefix}, however Josef mentioned ggzdexecmoddir as the correct variable (note the extra d). ggzdexecmoddir gets set as you would expect. I'm not sure why ggzexecmoddir is set as it is, hopefully Josef can offer some clarification :)
ggzdexecmoddir is undefined in Makefile's in general, since it's only AC_SUBST'ed in ggz.m4 in the have_ggzdconfig=yes case.
Using exec_prefix would be correct I think. However, that should be internal to ggz(d)execmoddir, and it already uses that according to ggz.m4. I'm going to try this out with a couple of corner cases now. This variable will always be defined when GGZ_AC_SERVER was called. It needs an installation of ggzd present, unless [force] is given as its argument. Which is safe to do at the moment because nothing spectacular happens with the files, they're just being copied to where they would belong if an imaginary ggzd was installed into the same prefix.
The ggz.m4 in ggz svn now defines ggzexecmoddir="\${libdir}/ggz". If ggz.m4 in gnome-games is updated as part of bug #520599 then this bug should be completely fixed. It's worth pointing out that the FHS makes no mention of /usr/libexec and it is clear that /usr/lib is intended for internal binaries. This is how it is configured now, I just wanted to clarify things because the comments above don't seem to indicate that. "/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. 2 Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. 3"
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. http://svn.gnome.org/viewvc/gnome-games?view=revision&revision=7546 *** This bug has been marked as a duplicate of 520599 ***
This bug is being reassigned to the "general" component so we can close the ggz bugzilla component. Apologies for the mass email!