Re: contrib/sepgsql regression tests are a no-go

On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
>>> In fact, I've been wondering if we ought to go a step further and not
>>> recurse into the sepgsql directory for *any* of the targets.  Then we
>>> could get rid of the associated configure option, which no longer
>>> serves any other purpose, and just say that if you want to build (or
>>> regression-test) sepgsql, well, you gotta go to that directory and do
>>> it by hand.
>
>> I'm not in favor of that.  It's nice to have a uniform interface that
>> decides what to build.
>
> Well, the right fix is to fix the sepgsql regression tests so that they
> adhere to the uniform model of being something you can run without
> destructive modifications to the host system.  What's being discussed at
> the moment is the least messy stopgap we can have until the tests are
> fixed.  I think that just taking sepgsql out of the subdirectory list
> (except for "make clean") might well be the most attractive workaround.
>
> Another possibility is to remove the Makefile's knowledge of how to run
> the tests, and change chkselinuxenv into something that both verifies
> the environment and then launches the tests.

That's not a bad fix, either.

I have my doubts about the theory that we'll ever be able to make
these regression tests work without some kind of support within the
system security policy. The whole point of MAC, for better or for
worse, is to make every decision to allow access made anywhere in the
system subject to veto by the system security policy. I'd certainly
be happy to find out that there's a way to make it work the way you're
hoping, but I'm not expecting it. Now maybe you'll say that we should
then remove the regression tests altogether, but I don't think that
having no regression tests is better than having regression tests that
are a pain-in-the-tail to run and most people won't.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company