There's a release of g-s-d already? Jon, I guess this one's for you, then.

*** Bug 504590 has been marked as a duplicate of this bug. ***

This is not yet fixed in 2.21.5.

2.21.5 does install however it won't start as the executable lands in /usr/lib/gnome-settings-daemon/gnome-settings-daemon while service points to /usr/lib/gnome-settings-daemon. Not sure about 2.21.5.1 as it won't build.

2.21.5.1 does install the daemon to /usr/lib/gnome-settings-daemon and the plugins to /usr/lib/gnome-settings-daemon/plugins, so it still does not work. 

*** Bug 511736 has been marked as a duplicate of this bug. ***

2008-01-28  Wouter Bolsterlee  <wbolster@svn.gnome.org>

        * data/org.gnome.SettingsDaemon.service.in:
        * src/Makefile.am:

        Hopefully allow $(libdir) to be the same directory as
        $(libexecdir) by installing the gnome-settings-daemon
        binary into a subdirectory of $(libexecdir), i.e.
        $(libexecdir)/gnome-settings-daemon/gnome-settings-daemon.
        Fixes bug #504203.

2008-01-28  Wouter Bolsterlee  <wbolster@svn.gnome.org>

        * src/Makefile.am:

        Don't use weird autofu stuff to install
        gnome-settings-daemon into another directory, but define
        gsddir and gsd_PROGRAMS instead. Fixes bug #504203.

14:46:32 < fcrozat> uws: make uninstall doesn't work with your fix
14:47:07 < uws> fcrozat: which version?
14:47:13 < uws> fcrozat: r74 is a better fix
14:47:24 < fcrozat> uws: r73 I guess (I'm just messenger :)
14:47:33 < uws> fcrozat: svn up
14:47:36 < uws> fcrozat: thx
14:54:33 < fcrozat> uws: confirmed, it works fine
14:58:51 < uws> fcrozat: Great, does this solve your issues?
14:59:12 < fcrozat> uws: apparently, yes

FYI: this change broke GDM which expects LIBEXEC /gnome-settings-daemon.

Then GDM should be fixed imho.

(In reply to comment #10)
> FYI: this change broke GDM which expects LIBEXEC /gnome-settings-daemon.

I filed bug #512745 for that.

Reopening since the Debian people complained. There was even a revert on SVN because of that:

  http://svn.gnome.org/viewvc/gnome-settings-daemon?view=revision&revision=78

...but I do NOT agree with that since that reintroduces the issue described in the original bug report.

It would seem to make more sense to me to fix this bug, and change GDM to expect g-s-d in the new location.  The only release of GDM that expects LIBEXEC/gnome-settings-daemon is the unstable 2.21 release.  So it shouldn't cause any stability issues to fix this in the GDM 2.21 release also.

(In reply to comment #14)
> It would seem to make more sense to me to fix this bug [...]

Point is that the "correct" fix for this bug is not ideal for all of debian, mandriva, and opensolaris. After some IRC discussion the fix will most probably be something like this:

  - Have the gnome-settings-daemon binary as $libexecdir/gnome-settings-daemon
  - Put the plugins in $libdir/gnome-settings-daemon-2.22

That way both libdir==libexecdir (mandriva, opensolaris) and libexecdir==subdir-of-libdir (debian, ubuntu) configurations would work.

Just a FYI, in FreeBSD:

libexecdir = $prefix/libexec
libdir = $prefix/lib

>  - Put the plugins in $libdir/gnome-settings-daemon-2.22

Or how about version of plugins rather than version of gnome-settings-daemon something like $libdir/gnome-settings-daemon-2.0 (or 1.0) ? That way other applications don't have to chase (change/reinstall) at the every version of gnome-settings-daemon.

I think Jeremy's idea makes a lot of sense - having the project version as opposed to API version would really be painful to maintain in the long term.

With respect to the GDM issue, it really shouldn't be looking for g-s-d in LIBEXECDIR, it should be using the pkg-config file to locate it, that way it would be always able to find it regardless of how a platform installs it.

Agreed. API/ABI version looks a lot more sensible than release number. Plus we have a pile of precedents in the platform.

The current plugins are internal to g-s-d so the numbering doesn't really matter, but a gnome-settings-daemon-plugins-1.0 where 1.0 is the ABI version sounds like a sane solution to me.

Now, if someone would cook up a patch... ;-)

FYI, it is broken again in 2.21.90.1, as g-s-d is installed in $libexecdir and the dbus service contains this:
Exec=@libexecdir@/gnome-settings-daemon/gnome-settings-daemon

Created attachment 104153 [details] [review]
Patch for lib/gnome-settings-daemon -> lib/gnome-settings-daemon-1.0

I think we should have the API/ABI version somewhere configurable in one central place, i.e. in configure.in, so that it can be easily bumped when API/ABI changes in the future.

Btw, epiphany uses this in its configure.ac:

EPIPHANY_API_VERSION=2.22

Created attachment 104217 [details] [review]
updated patch

Much simpler now that bug 513246 is in: just redefine the plugindir in configure.

        * configure.ac: Install the settings plugin to
        $(libdir)/gnome-settings-daemon-2.0. Fixes install with libdir ==
        libexecdir, bug #504203.

2.0 or 1.0? ;-)

It was committed with api-version 2.0 as per discussion with fizz on irc.