Re: [Summary] gdm bug#133578
I think that Henning Makholm summarized it nicely:
Is /etc/environment intended to configure environment variables
only for processes that run in the context of an authenticated
session, or is it also appropriate for other programs that interact
with users in non-authenticated contexts to adhere to locale
settings (et cetera) in /etc/environment?
In the latter case, is it appropriate for other programs to parse
/etc/environment themselves, or should such parsing be done through
an API controlled by whatever (source?) package is deemed to "own"
/etc/environment?
Definition of this file on AIX is:
The /etc/environment file contains variables specifying the basic
environment for all processes. When a new process begins, the exec
subroutine makes an array of strings available that have the form
Name=Value. This array of strings is called the environment. Each
name defined by one of the strings is called an environment variable
or shell variable. The exec subroutine allows the entire environment
to be set at one time.
Environment variables are examined when a command starts
running. The environment of a process is not changed by altering the
/etc/ environment file. Any processes that were started prior to the
change to the /etc/environment file must be restarted if the change
is to take effect for those processes. If the TZ variable is
changed, the cron daemon must be restarted, because this variable is
used to determine the current local time.
I was not able to google out something like that for linux, so
if somebody could add it here, I would be happy.
**
Sam Hartman, PAM maintainer is "perfectly happy for /etc/environment to
be a public interface for user environment variables" in his mail
[🔎] tsl1xmel9hd.fsf@konishi-polis.mit.edu and is willing to even provide
tool for getting values out of it.
I think that this issue was properly debated in debian-devel and should
be passed to tech-ctte and stop those insults as seen in few last posts.
If we want to make proper fix, we first need to resolve this issue.
O.
On Fri, 2004-04-23 at 18:43 -0300, Daniel Ruoso wrote:
> As the discussion proceeds, I think it would be interesting to
> reorganize the ideas, so I'll try to make a summary of the points raised
> until now (please correct me if I misunderstood, misinterpretated, or
> even forgot something)...
>
> I think we got two points here:
>
> 1) There is a bug standing for more than two years. There is a patch
> that, in the worst case, is a workaround for this bug. This workaround
> (or fix) doesn't breaks anything (at least at this moment, nobody
> pointed a specific problem). As no other fix was provided until now, the
> request is to fix the bug with the given patch.
>
> I couldn't find the arguments against this question, except Ryan Murray
> that said "No patch that involves doing anything with the PAM login-time
> configuration file /etc/environment is going to be applied by me."
> (sorry, but I have no time right now to search the history URL, but it
> is in this thread at Apr 19)
>
> 2) The file /etc/environment can be a "public interface for user
> environment variables" (Sam Hartman, Apr 23, (again sorry for the
> missing URL)) and I couldn't find where it is defined as a "PAM
> login-time configuration file". It *is* read by pam_env module, but
> that's all. And it is the only place where the System's Default Locale
> is saved (see locales postinst). So I don't see why /etc/environment
> couldn't be parsed in init scripts.
>
> The argument against this point is that /etc/environment *is* a "user
> session" configuration file, and, as init scripts aren't inside a "user
> session", it must not be parsed. The default locale should be saved in
> other file that could be parsed inside init scripts. There is another
> option that differs system's default locale of user's default locale
> (but I didn't read much about this, it's in the bug history, I think).
>
>
>
> let's move on, this discussion seems constructive...
>
> daniel
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
Ondřej Surý <ondrej@sury.org>
Reply to: