Any pointers as to why (really) I'm getting this error when I try to
install Pg 7.4 from a SRPM build?

perl(Pg) is needed by postgresql-contrib-7.4-0.2PGDG

I only disabled tcl, tkpkg, pltcl, and python in the SPEC file. I could
not install the contrib stuff but I really want the plperl and plperlu
languages.

Or should I take this to the ports list?


TIA,
Rod
--
"Open Source Software - Usually you get more than you pay for..."
"Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL"



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Roderick A. Anderson writes:
[color=blue]
> Any pointers as to why (really) I'm getting this error when I try to
> install Pg 7.4 from a SRPM build?
>
> perl(Pg) is needed by postgresql-contrib-7.4-0.2PGDG[/color]

As the message says, one package requires the other.
[color=blue]
> I only disabled tcl, tkpkg, pltcl, and python in the SPEC file. I could
> not install the contrib stuff but I really want the plperl and plperlu
> languages.[/color]

These languages are not in the -contrib package.

--
Peter Eisentraut peter_e@gmx.net


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

On Monday 01 December 2003 05:49 pm, Roderick A. Anderson wrote:[color=blue]
> Any pointers as to why (really) I'm getting this error when I try to
> install Pg 7.4 from a SRPM build?[/color]
[color=blue]
> perl(Pg) is needed by postgresql-contrib-7.4-0.2PGDG[/color]

Because Pg is no longer distributed as a part of the main tarball, but a
contrib is being distributed that requires it. This is an issue with the
main tarball, not with the RPM packaging, IMO. Someone needs to step up to
the plate and build a Pg RPM that provides the Pg module, one that would
replace the old postgresql-perl subpackage (which no longer exists). If no
one else can do this, I can, but it's not high on my list of priorities.
[color=blue]
> I only disabled tcl, tkpkg, pltcl, and python in the SPEC file. I could
> not install the contrib stuff but I really want the plperl and plperlu
> languages.[/color]

plperl.so is in the postgresql-pl package. The Pg module is a client side
deal, not a server side PL.

The Rserv contrib is the only thing, AFAIK, that requires the old Pg module.
I don't really want to not distribute it, since I have historically
distributed the contrib tree intact. That may have to change, I guess.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

On Tue, 2 Dec 2003, Lamar Owen wrote:
[color=blue]
> Because Pg is no longer distributed as a part of the main tarball, but a
> contrib is being distributed that requires it. This is an issue with the
> main tarball, not with the RPM packaging, IMO. Someone needs to step up to
> the plate and build a Pg RPM that provides the Pg module, one that would
> replace the old postgresql-perl subpackage (which no longer exists). If no
> one else can do this, I can, but it's not high on my list of priorities.[/color]

What you have a life? :-) OK it is slowly seeping in into my gray
matter. This 'perl(Pg)' is what the was/is/can be replaced by DBI and
DBD::Pg. Is this correct? I had it in my mind this was the plperl and
plperlu stuff.
[color=blue][color=green]
> > I only disabled tcl, tkpkg, pltcl, and python in the SPEC file. I could
> > not install the contrib stuff but I really want the plperl and plperlu
> > languages.[/color]
>
> plperl.so is in the postgresql-pl package. The Pg module is a client side
> deal, not a server side PL.[/color]

Right, like I guesstimated above. Is 'the postgresql-pl package' a
separate RPM or part of the main or server RPM?
[color=blue]
> The Rserv contrib is the only thing, AFAIK, that requires the old Pg module.
> I don't really want to not distribute it, since I have historically
> distributed the contrib tree intact. That may have to change, I guess.[/color]

Well I vote (if that is an option) for making it simple enough for me to
install. *REALLY* simple!


Rod
--
"Open Source Software - Usually you get more than you pay for..."
"Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL"



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Tuesday 02 December 2003 06:05 pm, Roderick A. Anderson wrote:[color=blue]
> On Tue, 2 Dec 2003, Lamar Owen wrote:[color=green]
> > exists). If no one else can do this, I can, but it's not high on my list
> > of priorities.[/color][/color]
[color=blue]
> What you have a life? :-)[/color]

And four kids....oh, that's an 'l', not a 'w'.... :-)
[color=blue]
> OK it is slowly seeping in into my gray
> matter. This 'perl(Pg)' is what the was/is/can be replaced by DBI and
> DBD::Pg. Is this correct?[/color]

This is correct.
[color=blue]
> Right, like I guesstimated above. Is 'the postgresql-pl package' a
> separate RPM or part of the main or server RPM?[/color]

Separate RPM, named postgresql-pl-7.4-whatever-version.arch.rpm
[color=blue]
> Well I vote (if that is an option) for making it simple enough for me to
> install. *REALLY* simple![/color]

I'll look at it. That is currently one of the smaller worries I have,
unfortunately.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org