Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] SRPM for 8.0.0 beta?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,Joe Conway <mail(at)joeconway(dot)com>, Steve Bergman <steve(at)rueb(dot)com>,"Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>,pgsql-admin(at)postgresql(dot)org
Subject: Re: [HACKERS] SRPM for 8.0.0 beta?
Date: 2004-08-18 16:10:20
Message-ID: 336.1092845420@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-generalpgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> In the PG case a
>> single specfile currently aggregates the core server, jdbc, and
>> pygresql ... and I'm getting pressure to include more stuff.

> How does that compute, considering that everyone else appears to be 
> working on including less stuff?

Well, *Marc* is working on including less stuff; the rest of us don't
necessarily agree.  In particular I've got to re-incorporate any major
pieces that get removed from the core distribution, since people expect
to find those in the RPM set.  (In principle I suppose they could be
handled as independent packages with independent specfiles, but so far
the path of least resistance has been to keep 'em bundled together.)

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-08-18 16:16:35
Subject: Re: 7.4.3 & 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Previous:From: Andrew DunstanDate: 2004-08-18 16:00:06
Subject: Re: 7.4.3 & 8.0.0beta1 + Solaris 9: default pg_hba.conf

pgsql-admin by date

Next:From: Joe ConwayDate: 2004-08-18 16:21:17
Subject: Re: [HACKERS] SRPM for 8.0.0 beta?
Previous:From: Peter EisentrautDate: 2004-08-18 15:55:21
Subject: Re: [HACKERS] SRPM for 8.0.0 beta?

pgsql-general by date

Next:From: Chris TraversDate: 2004-08-18 16:11:19
Subject: Re: pg_dump feature request: Exclude tables?
Previous:From: Greg StarkDate: 2004-08-18 16:06:05
Subject: Re: Problem analyzing performance of query

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group