Thread

1. RPM: Contrib request.

   Lamar Owen <lamar.owen@wgcr.org> — 2001-01-25T18:25:35Z

   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
   
   

2. Re: RPM: Contrib request.

   Peter Eisentraut <peter_e@gmx.net> — 2001-01-25T19:08:40Z

   Lamar Owen writes:
   
   > 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,
   
   It doesn't work to build contrib items without a source tree available.
   (At least Makefile.global and Makefile.shlib are necessary.)
   
   > 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.
   
   Maybe they could be grouped into a couple of packages.
   
   > 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??
   
   It shouldn't be packaged at all because it's not necessary.  (pg_dump
   dumps large objects.)
   
   -- 
   Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/
   
   
   

3. Re: RPM: Contrib request.

   Randy Hall <rhall@greatbridge.com> — 2001-01-25T20:02:11Z

   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
   
   

4. Re: RPM: Contrib request.

   Karel Zak <zakkr@zf.jcu.cz> — 2001-01-26T02:14:06Z

   On Thu, 25 Jan 2001, Lamar Owen wrote:
   
   > 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?? 
   
    ..ignore it. Not needful for 7.1, but can be interesting for < 7.1 
   (old DB users can found it directly on source tree, ftp ..etc.)
   
   				Karel
   
   
   
   
   

5. Re: RPM: Contrib request.

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-26T04:51:09Z

   Peter Eisentraut <peter_e@gmx.net> writes:
   >> 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??
   
   > It shouldn't be packaged at all because it's not necessary.  (pg_dump
   > dumps large objects.)
   
   The reason pg_dumplo is still there at all is that it might be handy for
   forward compatibility for people who are using pg_dumplo with 7.0.
   (Yeah, I know it wasn't *in* the 7.0 release, but I've been sending out
   7.0-compatible copies to anyone who asked about LO dumping lately.)
   
   I don't think pg_dumplo will be around for very many releases, but it
   deserves to stay in contrib for a little while yet.
   
   Meanwhile, it's not the RPMs' place to editorialize on which contrib
   items are useful.  Package 'em all, unless we hit build problems.
   
   			regards, tom lane
   
   

6. Re: RPM: Contrib request.

   Lamar Owen <lamar.owen@wgcr.org> — 2001-01-27T13:09:55Z

   Tom Lane wrote:
   > Meanwhile, it's not the RPMs' place to editorialize on which contrib
   > items are useful.  Package 'em all, unless we hit build problems.
   
   Interesting point of view :-).  Going into 'Uncle Martin' mode (obscure
   joke alert...).
   --
   Lamar Owen
   WGCR Internet Radio
   1 Peter 4:11