After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 274355 - evolution-data-server can't be installed correctly on a FHS 2.2 compliant system
evolution-data-server can't be installed correctly on a FHS 2.2 compliant system
Status: RESOLVED OBSOLETE
Product: evolution-data-server
Classification: Platform
Component: general
1.2.x (obsolete)
Other All
: High normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2005-04-03 21:19 UTC by Christian Krause
Modified: 2009-10-27 17:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch changes the location of the eds-binary (3.56 KB, patch)
2005-04-03 21:21 UTC, Christian Krause
reviewed Details | Review

Description Christian Krause 2005-04-03 21:19:26 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/
Comment 1 Christian Krause 2005-04-03 21:21:27 UTC
Created attachment 45055 [details] [review]
patch changes the location of the eds-binary
Comment 2 Christian Krause 2005-04-14 07:50:42 UTC
severity: enhancement -> normal, because it's a bug and no enhancement ;-)
Comment 3 Kjartan Maraas 2007-01-25 14:27:28 UTC
Please, someone review this patch.
Comment 4 Matthew Barnes 2007-03-26 03:40:33 UTC
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
Comment 5 Ross Burton 2007-08-28 14:52:42 UTC
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.
Comment 6 Matthew Barnes 2007-08-28 16:37:15 UTC
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?
Comment 7 Christian Krause 2007-09-10 21:47:06 UTC
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
Comment 8 Matthew Barnes 2009-10-27 17:22:20 UTC
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.