This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] test-in-container: Do not set GCONV_PATH, LOCPATH
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, DJ Delorie <dj at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 23 May 2019 09:22:11 -0500
- Subject: Re: [PATCH] test-in-container: Do not set GCONV_PATH, LOCPATH
- References: <xno93whrej.fsf@greed.delorie.com> <87d0k9xodo.fsf@oldenburg2.str.redhat.com>
On 5/23/19 8:59 AM, Florian Weimer wrote:
> * DJ Delorie:
>
>> Florian Weimer <fweimer@redhat.com> writes:
>>> Sorry, I don't understand. Why would the user want to run distcc *in
>>> the container*?
>>
>> That was just an example of an environment variable that affects the
>> build. I don't know what environment variables affect the test cases.
>> Timeout-related? Without a review of *every* test that might be run in
>> a container, we won't know what environment variables are valid for the
>> user to specify.
>
> But right now, only new tests run in a container, so I think we should
> focus on what helps us to write such new tests, so that they run in an
> environment that is as realistic as possible.
>
> We do not have many environment dependencies in the test harness itself:
>
> support/support_test_main.c: char *envstr_timeoutfactor = getenv ("TIMEOUTFACTOR");
> support/support_test_main.c: test_dir = getenv ("TMPDIR");
> support/support_test_main.c: const char *envstr_direct = getenv ("TEST_DIRECT");
> support/support_test_main.c: const char *coredumps = getenv ("TEST_COREDUMPS");
>
> TIMEOUTFACTOR and TEST_COREDUMPS are relevant, I think, and should not
> be filtered out. But TMPDIR and TEST_DIRECT are unlikely to work
> because they specify paths which may not be relevant in the chroot.
I agree.
I expect many refinements like this which hone our concept
of what it means to run a test in a clean environment.
Initially when we did the implementation we needed to keep
the environment variables because historically DJ's testing
included running *every* test through test-in-container just
to prove we could and see if anything failed. This was good
during the bootstrap process of writing test-in-container.
However, now that we have test-in-container upstream, we have
to use a guiding principle to make decisions.
I would suggest that test-in-container's initial environment
should be as clean as possible, free of any host environment
variables. Then the test sets whatever environment variables
are required. The only environment variables that are worth
passing down are those related to test framework control
e.g. TIMEOUTFACTOR.
--
Cheers,
Carlos.