RPM: Contrib request.

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)
and the 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 deed and 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