Обсуждение: [RPM] Suggestion for postgresql rpm spec file

Hi (is this going to Lamar?),

First, thanks so much for providing an RPM spec file for postgresql.  I
use it in my business and I really really appreciate all your hard work.

In order to make my production environment a bit more manageable/robust,
I routinely edit spec files to make them relocatable.  I wonder if this
might not be a good general enhancement to the spec file.  Of course,
it's not without its own issues.

We run a webserver which uses a postgresql backend.  We have the bare
OS on one hot swap disk and the database on another.  The database
code is on its own partition which is untouched through an OS
upgrade. That way, the OS and database can be upgraded independently.
However, this requires changing the install locations of most of the
postgresql package.

My standard spec file edit involves adding a '%define installprefix <dir>'
at the top, and propagating it down through the spec file.  For most
packages, this is mostly straightforward.  The use of built in RPM location
macros such as '%{_mandir}' are problematic, of course.  (I'd like to see
rpm itself upgraded to handle this situation directly.)

For postgresql, I similarly redefine the database location to live
on a nonstandard partition.  This allows me to safely and independently
upgrade the OS and postgresql.

I do this with most of my "add-on" software, because otherwise I have
too many issues with a distribution upgrade requiring too many simultaneous
upgrades.

It seems like this should be a standard feature of most spec files, much
like the 'DESTDIR' feature of a well written Makefile.  It allows lots
of needed flexibility with a very small cost.

Again, thanks very much for your contributions; they are greatly
appreciated here.  I'd be happy to help or discuss this further if it
is of any interest to you.

Sincerely,
Dave Hollenbeck
<http://www.edave.com>

...
> It seems like this should be a standard feature of most spec files, much
> like the 'DESTDIR' feature of a well written Makefile.  It allows lots
> of needed flexibility with a very small cost.

But only if it works for a particular application. I'm not *certain*
that the relocatable feature of RPM can be used for PostgreSQL, though
if it can I agree it would be desirable.

One of the issues is this: for some applications, parameters set during
the build process preclude their being relocated later on. For example,
PGDATA is set to a default value during the configure step. If that
parameter is required to have the correct value for applications to run,
then the application can not be relocated in the RPM sense.

We might agree that PGDATA is *not* required to match what was set at
build time, but we would need to inventory the other dependencies to
make sure that some other parameter is not constraining us.

And then someone would need to test it out, though it sounds like you
actually have tested this feature with one of your installations? Have
you done so with all of the PostgreSQL RPMs?

                       - Thomas