F45 Change Proposal: Use Systemd For Managing Per User Environment Variables [SelfContained]

I agree but I think it is difficult to agree on a proposal as long as I don’t have the full picture of how many user environment variable configuration files (inside and outside of systemd) exist and in which order they are loaded and in which file I should finally perform my environment modifications. (as long as these files are not consolidated it is just one more configuration file to maintain)

The number of files is theoretically infinite as I don’t think systemd has any limit.

The configuration for environment.d works similarly to other hierarchical systemd configuration files. (units, overrides, etc)

Systemd provides a path for the vendor to define the configuration, a path for the administrator to place override and configuration and finally a path for the user to do the same.

  1. Path(s) for vendor: /usr/lib/environment.d and /usr/local/lib/environment.d
  2. Path for the administrator: /etc/environment.d
  3. Path for the user: ~/.config/environment.d

(there is another directory in the docs but arguably not for human usage)

The precedence is therefore 3 overrides 2 which overrides 1. Within the directories the files would be sorted lexicographically and applied in order (latest file wins).

In any case you (the user) could override the PATH by creating a new file ~/.config/environment.d/99999-override.conf and setting the new PATH there.

It does seem like the original proposal does not specify which file would be created but the specifics can be worked out once there is a solution for the more fundamental problem of the environment not propagating on ssh sessions.

What is the priority if I set the environment in “~/.config/systemd/user.conf“ using “DefaultEnvironment=…“?

An alternative, more flexible (in terms of scripting) way to set environment variables would be to write an environment generator and save the generator in “$XDG_CONFIG_HOME/systemd/user-environment-generators/*“ or “$HOME/.local/lib/systemd/user-environment-generators/*“. This is currently a feature request - see “https://github.com/systemd/systemd/issues/32423“ but there exists a workaround to achieve this functionality (see link).

This change has been rejected by FESCo and will not be included in Fedora Linux 45.
To find out more about how our changes policy works, please visit our docs site.

FESCo Issue: Making sure you're not a bot!