It’s a place we mention as a supported location for local environment variables.
However, to support this we’ve to increase the delta with both debian and upstream in gdm (as per using user_readenv=1 ) and a patch to ignore gdm’s langauge settings.
Sooo… I’m wondering whether this still make sense now and if we can avoid supporting it.
gdm-side patches mentions g-c-c usage but the only reference I find there is in this g-c-c patch doc, but not in the code itself which is instead in language-selector-gnome (still a target for removal IMHO).
@gunnarhj maybe do you have opionions whether we can handle this better?
Hey, you forgot to mention three related patches in accountsservice.
Since you mentioned language-selector-gnome as a target for removal, there are two important things to keep in mind:
We have the language packs. No such thing exists in the GNOME world, and language-selector-gnome is the only tool we have to install/uninstall those. @darkxst succeeded in replacing language-selector-gnome in Ubuntu GNOME via a set of other patches, but if I recall it correctly it only worked as expected for a short time. Then some important dependency (don’t remember which one) was dropped which broke the feature, and we had to keep language-selector-gnome when Ubuntu switched to GNOME in 17.10.
language-selector-gnome is used also by some flavors (MATE, Xubuntu, Kylin, Unity) for dealing with language and formats related locale settings. So while it would be possible to revive the feature for installing/removing language packs via g-c-c, and with that drop quite a few of the current patches in different packages and drop language-selector-gnome, we’d leave those flavors to their fate.
(There are a few other details, but I won’t tire you with those ATM.)
But let’s return to the actual reason for this topic. Even if ~/.pam_environment was hijacked by accountsservice for storing the user settings, ~/.pam_environment isn’t holy. Even if we keep the current cross flavor solution for dealing with locales, I suppose it would be possible to store those settings somewhere else.
OTOH: Possibly the ~/.pam_environment usage can be motivated on its own merits. I think user_readenv=1 was there before accountsservice started to write stuff to ~/.pam_environment. So as a first step I would recommend to make sure that there is a consensus about the ~/.pam_environment usage not being desirable for anything else.
