Comment 70 for bug 1685754

Revision history for this message
In , Reuben Thomas (rrt) wrote :

(In reply to Christian Persch from comment #37)
> (In reply to Reuben Thomas from comment #36)
> > This is the bug that needs to be fixed: from a GNOME user's point of view,
> > systemd is an implementation detail, which has now (unfortunately) become
> > visible: a classic leaky abstraction.
> >
> > So GNOME needs to be fixed so that the entire user session is always run in
> > the scope of the user's .profile.
>
> That won't work, since the systemd --user instance will itself not see
> anything in .profile since it doesn't take its configuration from the
> environment, and thus still use its own default for umask, etc., when
> autostarting dbus services.

It doesn't make sense to say "this won't work". It needs to be made to work. GNOME has decided to use systemd as an optional component, which is fine, and a long-standing expected behaviour has been broken as a result. This needs fixing. How best to do this is of course a matter for GNOME developers; users are just concerned with observable results.

In this case, the observable result is that a de facto standard behaviour, namely that the user session runs in the scope of .profile, is broken.

You can see from the design of other desktops, PAM, ssh, dbus etc., all of which accommodate this expectation, that it is indeed a standard, even if it's not explicitly laid down in broad terms.

> IMHO, the problem here is simply mismatched expectations: you expect that
> .profile is where you configure these things, but this isn't the case
> (anymore). The actual place to configure these is where systemd --user gets
> its defaults from. That's not a 'leaky abstraction', it's only a *change*.

If this is an intentional change, then it should be discussed at a high level (please point to such discussion if I've missed it), documented in release notes etc., because it's a big and breaking change to traditional behaviour.

Further, in this case there should be a documented migration path which does not involve having to have duplicate settings. If users should use something other than .profile for setting environment variables, umask &c., that needs to be documented, and of course it should work in the other direction, that is, the user's settings should be transmitted appropriately to shells, console logins, other desktop environments etc.

Since I see no evidence that a change of this magnitude was intended (again, I'm happy to be corrected), I have assumed it is a bug. Many users will simply experience it as a bug (or series of bugs) whether it was intended or not.

In any case, putting a new mechanism in place will be a lot of work, and it might be easier simply to keep things backwards-compatible.