Bug#251953: gnome-settings-daemon not in default PATH

[Marcelo E. Magallon]

Hi,

On Tue, Jun 01, 2004 at 11:10:11AM +0200, Sebastien Bacher wrote:

 > >  I'd like to have the opinion of the rest of the GNOME maintainers,
 > >  if you don't mind.
 > 
 > I don't want to start an endless thread. 

 I beg your pardon?  You don't agree with the bug but you don't want to
 have a discussion either?

 > My point is that was not document/warranty saying that calling
 > settings-daemon is designed to be runned by user and should be in the
 > path.

 Ignoring my requests isn't going to change them.  Go fish the GNOME API
 docs.  I can't find a documented way for a program that _needs_
 gnome-settings-daemon to be running to start it.  AFAIU the
 documentation a program _isn't_ supposed to start gnome-settings-daemon
 by itself.  By desing it's started in the session.  I happen to start
 it in ~/.xsession.

 What I am saying is that if I _have_ to start this thing for Epiphany
 and what not to run the way I'm configuring them to do (e.g. I don't
 want to have text beside icons in the toolbars), I am not going to
 chase this thing around all over the place.  I use systems that have
 GNOME in /usr, others in /opt, others in /usr/local.  I have testing
 and unstable Debian boxes.  Testing has this in /usr/bin, unstable now
 has this in /usr/lib/whatever.  What's the _technical_ reason for
 removing this from the default PATH?  "Users aren't supposed to run
 this directly" isn't because _by design_ users are supposed to start
 this thing.  gnome-session just happens to be a crotch that does this
 for the "regular" GNOME user.

 Put it in another way.  I use Nautilus in non-root mode every now and
 then.  I use dia-gnome, and other "-gnome" flavours of some packages
 because they give me a usable print dialog.  I use Epiphany as my web
 browser because I can configure it _not to display_ a bunch of garbage
 on the browser window.  Now, how exactly am I _not_ running GNOME?  Is
 it the panel that I don't use?  I though GNOME was about a network
 object model environment, not about a silly panel.

 > You've written a script that use something that has changed, but it's
 > your responsability since you've written the script. We can't support
 > all users scripts ... 

 Sorry, that doesn't fly.

 This is about an application that's to be started by users not being in
 the user's PATH.  This is not about _my_ X Session script.  For me this
 happens to be an annoyance that's fixed with a few more lines in a
 shell script.

 > - use a window manager/environment that handle settings : that's the
 > job of this environment (ie: xfce does that).

 Sorry, this is not the _window_ _manager_'s job.  Window Managers
 manage windows.  As for the "environment", no, that's not it either.

 This belongs in the X Session, and _there's_ where I have it.  _My_ X
 Session is simplistic because that's all I need.

 > - launch it by hand: so use the right path ...

      4.2  /usr/bin : Most user commands

      This is the primary directory of executable commands on the
      system.

 That's included by Debian Policy.  And breaking it is "serious".

 > I agree we should put a NEWS.Debian entry about this but that's all,
 > moving the settings-daemon in path is probably a wontfix. I'll still
 > try to give a shot with upstream but don't expect changes on this
 > side.

 Nope.  Not enough.  Think bigger.  Think multiuser.

 > BTW I still believe that's an application problem and not a
 > control-center one. If settings daemon is not running the apps should
 > perhaps show a warning or something like that.

 Nope, that's not the way this thing is designed to work.  "Good
 defaults", "consistent user experience", "intuitive behaviour" and all
 that.

 Marcelo