On Wed, Mar 27, 2013 at 12:54:41PM +0000, adrelanos wrote:
> Package: general
> Severity: wishlist
> I'd like to have a /etc/environment.d folder. Contributing that code
> shouldn't be hard for me. But I don't know where the would be the best
> place to implement it and how?
As Joss says, packages should not rely on /etc/environment's contents;
there should be no need to manage this as anything other than a simple file
under the control of the user.
> http://codesearch.debian.net tells, that many packages read
> /etc/environment directly, not using some system mechanism to get the
> contents of it, which makes the implementation harder.
The /etc/environment file is owned by pam. Other packages are not meant to
be reading it directly, because contrary to appearances it is NOT defined as
a shell snippet, but as a shell-like config file parsed by pam_env
internally. Packages *are* allowed to assume /etc/default/locale is
shell-parseable and parse it directly, as this is a file defined expressly
for sharing locale information between all relevant consumers (including pam
services, and display managers which need to know the locale to use /before/
authenticating the user).
And I would not accept a patch like this to the pam package. pam's code is
very security-sensitive, which makes this a high-risk, low-benefit change.
It should be done upstream if at all, but I don't think upstream will go for
> Asking all affected packages to read /etc/environment.d as well or to
> start using a system function to do that seems unlikely?
> The most realistic option could be to write something similar to
> resolvconf, i.e. creating a package which phrases /etc/environment.d
> and dynamically creates /etc/environment.
That would at least not require changes to pam_env, but having to generate
files in /etc from other files is ugly and should be avoided unless
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/