GNOME Bugzilla – Bug 274355
evolution-data-server can't be installed correctly on a FHS 2.2 compliant system
Last modified: 2009-10-27 17:22:20 UTC
eds wants to install the binary evolution-data-server-1.2 in LIBEXECDIR. Additionally it creates the directory LIBDIR/evolution-data-server-1.2. On FHS[1] compliant systems LIBEXECDIR points to the same location as LIBDIR. This means that during the installation the directory /usr/lib/evolution-data-server-1.2 is created and later the binary evolution-data-server is copied to /usr/lib/evolution-data-server-1.2. But because there is already a directory with this name, the binary is copied into this directory. Because of this eds doesn't find the binary, because the compiled-in path of the evolution-data-server binary is still /usr/lib/evolution-data-server-1.2. I've attached a patch which moves the binary (without the version prefix) into the directory /usr/lib/evolution-data-server-@VERSION@. [1]: http://www.pathname.com/fhs/
Created attachment 45055 [details] [review] patch changes the location of the eds-binary
severity: enhancement -> normal, because it's a bug and no enhancement ;-)
Please, someone review this patch.
In server.c please use g_build_filename() [1] to construct file paths. Otherwise the patch looks okay to me. I'll let one of the other developers make the final call on this since the location of the binary is a policy decision. [1] http://developer.gnome.org/doc/API/2.0/glib/glib-Miscellaneous-Utility-Functions.html#id2767532
It's my understanding that on a FHS compliant systems, libexecdir is /usr/lib/evolution-data-server/ not /usr/lib/evolution-data-server-1.2.
I'd love to see the "-1.2" just get dropped altogether; it's no longer meaningful as far as I can tell. If packages are using pkg-config properly I think they would just need to be rebuilt to adapt to the change, yes?
Hi Ross, (In reply to comment #5) > It's my understanding that on a FHS compliant systems, libexecdir is > /usr/lib/evolution-data-server/ not /usr/lib/evolution-data-server-1.2. During the time I wrote the CR I've used a self-made FHS compliant linux system (which didn't had "/usr/libexec"). So usually the variable libexecdir within the auto* tool-chain pointed to "/usr/lib". As far as I remember the installation process wanted to install the executable into $libexecdir with the name evolution-data-server-1.2. Additionally it created the directory $libdir/evolution-data-server-1.2. So there was a naming conflict, because on a FHS system the paths would be /usr/lib/evolution-data-server-1.2 (binary) and /usr/lib/evolution-data-server-1.2 (directory) Because the binary was copied later with the destination $libexecdir/evolution-data-server-1.2. So the copy (or install) program recognized, that that there is already a directory with the same name and so it copied the binary into this directory instead of giving the binary the destination as name. The patch I've originally provided worked for me for a very long time... ;-) It just put the binary not directly into libexecdir but into the directory libexecdir/evolution-data-server-@VERSION@/ with the filename having the version omitted @comment #4: My patch was very small and didn't changed anything regarding the used functions to put the path together. So I've sticked to the original design but just adjusted the paths itself... Nevertheless this is long ago and I've already switched to Fedora (using /usr/libexec and so violating the FHS ;-) ) in the meantime. So you may also close the Bug as WONTFIX if you want... Best regards, Christian
The evolution-data-server-1.2 binary no longer exists in 2.29 -- it's been replaced by separate D-Bus services: e-addressbook-factory and e-calendar-factory. So I guess the issues has resolved itself. Closing this as OBSOLETE.