[Pkg-xfce-devel] Bug#752129: Bug#752129: lightdm: Shell profile startup files not sourced on login

[Daniel Richard G.]

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
this right.

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.