Re: Two weeks to feature freeze

From: Thomas Swan <tswan(at)idigx(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Two weeks to feature freeze
Date: 2003-06-27 15:43:04
Message-ID: 3EFC6608.2050007@idigx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:

>Thomas Swan writes:
>
>
>
>>I just am really concerned about the uninstall/clean up phase and how
>>that can be done in an orderly fashion. Unless the process can start
>>from a clean state again, then it won't be valid.
>>
>>
>
>The only clean state is if you remove the entire source tree and check it
>out again. (Of course to save bandwidth, you copy the checked out source
>tree to a temporary location, do your testing, and then remove that
>temporary tree.) Relying on make clean or make uninstall is flawed,
>because those are among the things you want to test.
>
That sounds plausible. Should we let everything stay in the compilers
directory. Something like the configure --prefix=$TEST_ROOT and that
way we can have the whole thing run as one user in one directory so that
system wide impact is minimal. I guess what I'm concerned with is
running this on a clean system, and then leaving unknown artifacts
behind. Can/does make install output each file it's copying and where
to. Capturing that output would make life easier for clean up of
things installed outside of the work directory, and provide a more
controlled environment.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2003-06-27 15:52:56 Re: pg_guc
Previous Message Josh Berkus 2003-06-27 15:39:21 Re: CODE SUBMISSION FOR NEXT RELEASE