Allow addition env vars to be defined in session files

[davidedmundson]

We have a continual problem with developers using Plasma in custom
prefixes. We need to set mulitple additional envs and it is a constant
pain point.

Setting XDG_DATA_DIRS and alike in a script in the Exec line of the
desktop file doesn't work properly, as this is after systemd and dbus
have already been started during pam_logind. It requires a lot of bodging.

Things will work much better if we can set the env before pam_logind is
run.

Using pam_env or profile.d doesn't really work correctly as that then affects all the
sessions.

This additional hint is not intended to be used for anything other than dev setups.

From a security point it should be safe, as you need root for xsession/xwayalnd files, and if you can edit them, you could just edit the Exec line.

[Vogtinator]

This is a DM specific hack, which means that anything which uses this key in session files will be subtly broken in a non-obvious way if the session is started otherwise, be it a different DM or launching it manually somehow.

Setting XDG_DATA_DIRS and alike in a script in the Exec line of the
desktop file doesn't work properly, as this is after systemd and dbus
have already been started during pam_logind. It requires a lot of bodging.

Is updating the startup environment before doing anything with systemd or DBus not sufficient?

[davidedmundson]

Is updating the startup environment before doing anything with systemd or DBus not sufficient?

It needs setting before systemd is launched, which is inside Pam.

That can be done before logging in, but that means it has to be always on and system wide with more manual steps for a dev setup.

[Vogtinator]

It needs setting before systemd is launched, which is inside Pam.

I get that, but why that early? Are there certain systemd user units starting before the actual session itself? That could be worked around by changing the environment in services which run even earlier.

[davidedmundson]

The problem isn't about the env anything that is spawned by systemd have. We have solutions for that and there aren't any ordering issues, it all works mostly great.

The problem that's left is making dbus-daemon / systemd itself able to find the right service files if those services files are installed to a prefix.

[Vogtinator]

The problem that's left is making dbus-daemon / systemd itself able to find the right service files if those services files are installed to a prefix.

Right. I wonder how this is supposed to work if you already have a running session? Let's assume you log in using the tty, then switch to sddm and log into the Plasma developer session. systemd isn't started twice, so it would use the wrong environment? Or the other way around, log into a development session, then log out and back into a non-development session. It'll use the wrong XDG_DATA_DIRS, won't it?