GNOME Bugzilla – Bug 143546
gnome-settings-daemon should be in PATH
Last modified: 2004-12-22 21:47:04 UTC
This bug has been reported in the debian BTS: http://bugs.debian.org/251953 "gnome-settings-daemon is started in the usual case by gnome-session. But there's really _nothing_ that says that this program is not to be run by the user, and there's a situation where the user might want to start it by himself: namely when not using gnome-sesison. In my particular case I need this otherwise unwanted piece of software because Epiphany will happyly ignore my preferences if gnome-settings-daemon isn't running. For that reason I start gnome-settings-daemon "by hand" in my .xsession. Since this thing is now hidden somewhere in /usr/lib, my .xsession can't find it and some programs that I use suddenly ignore the preferences I've set. Care to give me a reason for taking gnome-settings-daemon out of the default user's PATH?" Please see the debian bug report for details, we already had a discussion on this here. BTW I'm not sure of the best option ...
gnome-settings-daemon is not something I see as useful showing up in someones path. The huge majority of the time you don't want to run it. Note that I don't mean that it has to be run by gnome-session. My point is that it is run at startup, not run at arbitrary times from the command line. We have lots of as things are started. Running it from <prefix>/libexec does not seem overly burdensome.
Yeah, I tend to agree with that ... but have you read the arguments against that in the debian bug ? Mainly it breaks update of system using "gnome-settings-daemon" in their .xsession ... but perhaps is that a distribution's problem and not a gnome one ?
> The huge majority of the time you don't want to run it. This is true, but there are some cases where you want to. As these cases exist, it makes sense to put it in /usr/bin, as the FHS mandates. There are already many programs in /usr/bin that are not generally run by the user, but which can be useful sometimes.
I think we'll have to agree to disagree on this. Users can easily execute it from the explicit <prefix>/libexec path in their startup scripts. If it is a problem for debian based on existing scripts then you're welcome to make a debian specific symlink for the problem. To my mind the daemon belongs in libexec.
Yeah, in Debian we don't use $prefix/libexec, but rather set libexecdir to $prefix/lib/$package. This is another argument in favour of keeping at least a symlink in $prefix/bin.