Re: RFC: test-in-container vs ld.so

[Carlos O'Donell <carlos@redhat.com>]

On 11/7/19 5:31 PM, DJ Delorie wrote:
> 
> The glibc test infrastructure goes to great lengths to run test
> programs in the just-built environment, running env and ld.so with
> lots of arguments to get things "just right".
> 
> The test-in-container infrastructure goes to... well, less great
> lengths to provide a "correct native" environment for the test
> programs, yet it still runs env and ld.so within the container.
> 
> There are a few of our tests that sometimes fail due to kernel address
> space randomization when run under ld.so yet work correctly all the
> time when run directly.
> 
> So... should we run containerized tests without ld.so?
> 
> I see two discussion points...
> 
> 1. Are there tests that *need* the env/ld.so handling within the
> container?  (not counting test-specific environment variables, I mean
> the environment variables we pass to *every* test)

I don't think so.

I think everything that test-in-container does should emulate an
installed system.

If we have a *need* to run an ld.so test, that verifies running ld.so
directly works, we can do it outside of the test-in-container
infrastructure.

> 2. how complicated would it be to remove those from the makefile
> rules?  Alternatively, I suppose test-container itself could remove
> them, but better not to hide that logic.
 
test-in-container is already a distinct target. You would have to alter
the dependencies, and likely create a cloned rule that doesn't run ld.so
directly. I don't know how difficult this would be.

I think this is the right directly though. Test in container should not
run ld.so, it should run the binary directly.

You and I discussed this on the list while we were reviewing test-in-container,
but at the time the goal was to get the framework in place and emulating
exactly what the previous framework did except in a container.

The next logical step is to make test-in-container *more* like the installed
tree testing we want it to be.

-- 
Cheers,
Carlos.