Re: RPM: Contrib request. - Mailing list pgsql-hackers

From Randy Hall
Subject Re: RPM: Contrib request.
Date
Msg-id 3A708643.FA407417@greatbridge.com
Whole thread Raw
In response to RPM: Contrib request.  (Lamar Owen <lamar.owen@wgcr.org>)
Responses Re: RPM: Contrib request.
List pgsql-hackers
Now that pg_dump & pg_restore can handle large objects, the only need
for pg_dumplo is for migrating large objects from prior versions.  I
personally cannot see it being used on a day to day basis, but I'm
looking at it from a narrow perspective.  If it is a separate package,
it can easily be removed from a production system after data has been
migrated.  On the other hand, you never know when someone may need to
restore large objects from a pre 7.1 backup.  

I think the cleanest way to provide the contrib programs is to build a
postgresql-contrib with _everything_ in it.  Those people who need a
specific binary will be able to get it from /usr/lib/pgsql (or wherever)
and the distiction between core and contrib programs will not be fuzzy.

Lamar Owen wrote:
> 
> It has been requested that I ship prebuilt contrib items in the 7.1
> RPMset.  Currently, the source code of the whole contrib tree is being
> shipped in the main RPM as documentation, but only autoinc and refint
> are being prebuilt (as part of the -test subpackage).
> 
> I have had three different types of request on this:
> 1.)     The whole contrib tree prebuilt;
> 2.)     Select parts of the contrib tree prebuilt (geospatial stuff for the
> most part);
> 3.)     pg_dumplo.
> 
> Now, I see a couple of different ways I can go about doing this -- I can
> build a large 'postgresql-contrib' RPM (which would also eliminate the
> source of the contrib tree in the documentation -- possibly) containing
> the _whole_ tree, prebuilt (possibly in /usr/lib/pgsql (or postgresql --
> I'm not at all settled on the subdir naming scheme) -- OR, I can build
> individual RPMs for each contrib element.
> 
> But, in the instance of pg_dumplo -- can I get some ideas on it?  Should
> it be shipped as a separate package, or in the -server subpackage, or??
> I am open to suggestions.
> 
> If PORTS is a more appropriate list to post this, I will do that as
> well.
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11

-- 
---------------------------------------------------
Randy Hall                    Great Bridge, LLC
Sr. Knowledge Engineer        253 Monticello Avenue
Red Hat Certified Engineer    Norfolk, VA 23410


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]
Next
From: Frank Joerdens
Date:
Subject: Re: beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]