Thread: RPM: Contrib request.
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
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/
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
Randy Hall wrote: >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) >andthe distiction between core and contrib programs will not be fuzzy. This is what I do for the Debian release. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "My little children, let us not love in word, neither in tongue; but in deedand in truth." I John 3:18
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
Oliver Elphick wrote: > > Randy Hall wrote: > >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. > > This is what I do for the Debian release. Precedent set; precedent followed. I'll be hopefully packaging the _entire_ contrib tree :-) for beta 4, over the weekend. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> I think the cleanest way to provide the contrib programs is to build a
> postgresql-contrib with _everything_ in it.
>>
>> This is what I do for the Debian release.
> Precedent set; precedent followed. I'll be hopefully packaging the
> _entire_ contrib tree :-) for beta 4, over the weekend.
The only potential downside is that the contrib tree has (historically)
not been as much shaken out for portability bugs as the main tree.
You might find that some contrib items don't build, let alone run,
everywhere.
This probably isn't that big a danger for the RPMs, which only address
a narrow subset of Unixen, but I recommend keeping your antennae up
for possible problems.
regards, tom lane
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
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