On 30 January 2015 at 08:30, Simon McVittie <simon.mcvit...@collabora.co.uk> wrote: > Remaining issue: environment variables > ====================================== > > Sadly, not all the issues have been resolved yet. The biggest is > environment variables: on existing systems there is an expectation > that environment variables set by *dm, PAM, or /etc/X11/Xsession.d > (or the non-Debian equivalent) will be propagated into every process > in the session. In a brief survey of about half the Xsession.d scripts > in Debian, I identified these environment variables: > > * PULSE_SERVER > * ESPEAKER > * XDG_DATA_HOME, XDG_DATA_DIRS > * each variable printed by locale(1) > * VDPAU_DRIVER > * GTK_IM_MODULE, QT_IM_MODULE, QT4_IM_MODULE, CLUTTER_IM_MODULE, > XMODIFIERS > * GTK_MODULES >
And one shall not forget GNOME_DESKTOP_SESSION_ID=this-is-deprecated for a certain C++ toolkit to not look like it's 1995. ;-) > plus the obvious ones set by *dm, such as DISPLAY, or by PAM. Similarly, > a user's ~/.xsession can set arbitrary variables - mine sets CCACHE_DIR, > EDITOR, MPD_HOST and XDG_CONFIG_DIRS, among others. > > The naive implementation would be to run a tool at the end of > /etc/X11/Xsession.d that uploads all of these into `dbus-daemon > --session` (if used) and into `systemd --user` (if used). However, not > all environment variables set in such scripts are suitable for that use: > notably, XDG_SESSION_ID from the login session should not be copied into > activated processes that exist outside any login session. > The rest of the email thread is adequate. I would like to experiment with a user-bus, potentially in a transient manner to have 3 buses: system, user, session busses. And migrate things from session to user bus & experiment as to how much stuff breaks. I think being explicit about session vs user bus would avoid confusion, and will help manifest bugs & have a clear migration plan. E.g. when org.freedesktop.Telepathy / ca.desrt.dconf moves to user bus, things should know how to start talking to Telepathy/dconf over user bus. Looking at the stuff that I have on my session dbus, I see quite a few things that do interract with DISPLAY=:0, or rather create GUI windows and expect them to appear in the right place, as in on the currently active seat. Similarly they would need to be migrated/restarted if we ever allow multiple graphical search for a single UID. I wonder if this is at all an actual problem, maybe all current/sophisticated dbus-heavy DEs cannot in fact have multiple graphical sessions for the same UID, in which case switching to user bus today is non-regressing (given that current active graphical session cannot migrate a seat (?! not sure if this)). Going down this rabbit-hole, the only difference between current session-bus (e.g. where under gdm only one graphical login is allowed per UID) and the user-bus seems to be the life-time of the bus (tied from first login until last login V.S. X11 started and finished). That means that dbus-activated services have to simply become seat aware, and know that if they were started on a non-graphical seat, later on active seat might be graphical and thus they should migrate/recreate/create GUI windows on currently active seat - or across all seats if that's appropriate. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
