[Pkg-xfce-devel] Bug#752129: Bug#752129: lightdm: Shell profile startup files not sourced on login
Daniel Richard G.
skunk at iSKUNK.ORG
Sun Jun 22 20:59:34 UTC 2014
On Sun, 2014 Jun 22 10:34+0200, Yves-Alexis Perez wrote:
> Well, if you abuse the offered interface, then you have to deal with
> the fallouts yourself.
This is bog-standard *nix usage. Do you seriously believe that everyone
who starts agent programs in their ~/.profile is "abusing" the
interface? (What, in your view, would be the proper way?)
> There's a perfectly working solution which I already gave you. If you
> don't want to use it, then there's not much we can do.
~/.xsessionrc is not a "perfectly working solution" for two reasons:
1. As Julien Cristau explained in bug #752192 (message #10), X-session
setup is not the right place to run login initializations, because
there are cases where an X session can be started without it
representing a login (e.g. startx, Xnest). I believe the reasoning
behind his point that the display manager should do the
initializations is that only then is the X session necessarily
equivalent to a login session.
You could make the argument that ~/.xprofile is the proper place, and
that might even be a reasonable solution *if* that file were
supported and we also added an /etc/skel/.xprofile that sources
/etc/profile et al.
2. ~/.xsessionrc does not exist by default. The user has to create this
file, and before that, has to know to create this file. But login
initializations are supposed to happen *by default*. It is not, and
has never been an "opt-in" thing as you seem content to leave it.
The only reason you've given for your position is that /etc/profile et
al. are technically shell configuration files, and an X login is not a
shell login. This is a distinction without a difference, with no
historical support to back it up. Even Ubuntu---a distribution with much
less reason to support shell users and Unix legacy in general---gets
Feel free to articulate a better argument for your position, but I would
implore you to consider longstanding *nix precedent and use cases
different from your own. Otherwise, I think this will have to go to
tech-ctte, as the status quo represents either a major regression (IMO)
or a Debian design change that should be decided at that level.
More information about the Pkg-xfce-devel