Re: [pgsql-advocacy] Increased company involvement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [pgsql-advocacy] Increased company involvement
Date
Msg-id 24465.1115310772@sss.pgh.pa.us
Whole thread Raw
In response to Re: [pgsql-advocacy] Increased company involvement  (Josh Berkus <josh@agliodbs.com>)
Responses Re: [pgsql-advocacy] Increased company involvement  ("Marc G. Fournier" <scrappy@postgresql.org>)
Re: [pgsql-advocacy] Increased company involvement  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
>> But packaging them as separately buildable tarballs that depend only
>> on the installed core fileset (headers + pgxs) seems a fine idea.

> I really can't see doing this without a better (i.e. CPAN / emerge / ports - 
> like ) build system.    Mind you, I'd really like such a build system, but if
> we require users to manually download several separate tarballs and untar 
> them in exactly the right spot in the source tree, we're adding a bunch of 
> extra effort for both users and packagers.

Uh, that's not exactly what is being proposed.  It would be a separate
tarball that you could untar wherever you felt like, because it would
not depend on the core source tree at all --- only on the files
installed by a previous build of the core.

I think Marc just suggested having all the PLs in one such tarball,
rather than one for each which is what I was envisioning.  That would
probably fix the "too many things to download" issue.  Offhand it
doesn't seem like it makes the what-order-do-I-build-my-RPMs in problem
any worse.  It would complicate the license issue though.  For ease of
labeling you really want all the code in a given tarball to have the
same license, and we couldn't expect to have that for all the PLs.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement
Next
From: "Lance Obermeyer"
Date:
Subject: Re: Views, views, views! (long)