How about this fix on regression test of sepgsql? It disables to launch regression test together with other modules, and adds its own build target "sepgsql-installcheck" that launches chkselinuxenv script then pg_regress command as currently we are doing.
It allows users to launch regression test by hand, in same time, it also enables to build all the contrib modules on the rpm build environment without selinux ready. 2011/9/26 Robert Haas <robertmh...@gmail.com>: > On Mon, Sep 26, 2011 at 11:03 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>>> 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. >> >> The main point I'm on about here is that "make check" must not require >> root privileges. That is absolutely not negotiable (even if it were >> sane from a security standpoint, which is ridiculous anyway). I don't >> think "make installcheck" should require root either, although there >> might possibly be a little more wiggle room there. If it's infeasible >> to test sepgsql usefully without root involvement, then it can't be >> tested within the existing regression test framework. So maybe just >> pushing the issue out to a separate shell script that you can choose >> to invoke by hand is a reasonable compromise. >> >> I think it should be possible to still use all the existing testing >> infrastructure if the check/test script does something like >> make REGRESS="label dml misc" check >> >> BTW, I think this line of argument also casts serious doubt on whether >> REGRESS_PREP is a useful concept at all. I'm more than half tempted to >> revert the patches that added that to the regression test >> infrastructure. Do we still need the --launcher option, either? > > I want to be able to run these tests, but I'm not fussy about the > exact mechanism. If you want to whack it around so that I type > "./funky_sepgsql_regression_crap" instead of "make installcheck", > that's fine with me. And if that means you can rip out some > supporting infrastructure, that's fine too. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- KaiGai Kohei <kai...@kaigai.gr.jp>
sepgsql-fix-regtest.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
