[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#153612: Bug #153612 - xfree86-common: want a user file that gets executed regardless of the session type



Hi

I have a belief. Xsession is executed as the user that was just
logged.
Thus they are already user configuration files. Only that they
are in a system wide directory where user cannot write. 


I strongly disagree with for example:
> > if you'd be using kdm's upstream Xsession, it would source
> > ~/.profile
ahem .profile is bourne shell only. Is this a reasonable
dependency for kde ? and if all x session does then maybe all
shell should be hacked to source profile files ... .
It is nearly as good as RH sourcing /etc/environment and adding
shell commands in it ... 
At least using something like sysconfig would make it less brain
damaged.


But why couldn't a new /etc/X11/Xsession.d cript be
added to source a file in $HOME as the one in m17n-env ?
if [ -d $HOME/.xsession.d ]; then
  UXSESSIONS=$(run_parts $HOME/.xsession.d)
  if [ -n "$UXSESSIONS" ]; then
    for UX in $UXSESSIONS; do
      if [ -x "$UX" ]; then
        "$UX"
      else
        . "$UX"
      fi
    done
  fi
fi

Branden i do not understand your rationale for tagging this kind
of patch as wontfix : 
>A user X session file should *replace* the system's default X
>session, not augment it
standard Xsession, check the language, the Xsessions.option file,
check that the keyboard is in good shape. Some of the scripts in
/etc/X11/Xsession.d are from xfree (ressources, ssh agent, check on
available session/window manager , starting the thing). But it is
also the place where other X packages set their environment
(xprint, m17n, gnome-session, dbus).
Did you mean that the right way to fix this is to let a user set
an environment variable so he could replace the use of
/etc/X11/Xsession by say $HOME/Xsession. Thus having to rewrite
all the packages, keyboards, ssh tests if he wants to change his
PATH variable (for example so some menu items can find their data
in /opt ) ?
Or did you mean that the code to source those ~/.xsession.d files
should not be in /etc/X11/Xsession itself but in a script such as
the  /etc/X11/Xsession.d/40xfree86-common_user-xsession from
m17n-env ?

Regards
Alban




Reply to: