Re: Trimming the Fat, Part Deux ... - Mailing list pgsql-hackers

On Wednesday 31 July 2002 09:38 pm, Marc G. Fournier wrote:
> Okay ... since this is pretty much going to be 'one camp for, one camp
> against' without anything to really back up either camps perspectives /
> arguments, I did some research on CVS in order to find a nice, effective
> middle ground ... and it actually works quite sweet ...

MAn, did I ever pick a bad day to be offline for a whole day. :-)

If anyone cares to look, or for that matter cares at all, something similar is 
already being done in the binary RPMs.  I have split, sliced, and diced this 
distribution for over three years.  So, let me share some of the experiences 
learned from that exercise.

> Now comes the 'tricky part, which I'm hoping someone like Peter might know
> how to do ... I know there is a way of writing configure to 'run
> configure' in sub projects .. for instance, with libpqxx ... at the top
> level of pgsql, one could type:

> ./configure --enable-libpqxx

I like this idea, up to an extent.  I guess it boils down to this:
1.)    What is the minimum build environment necessary to build anything in the 
source distribution;
2.)    What degree of granularity is desired;
3.)    We must not assume the presence of a full source tree to build _anything_, 
only the minimum build system, which can then handle everything else as a 
module.

Then I could much more easily package a 'postgresql-devel' package that would 
allow, for instance, PostGIS to be built as a server module without having to 
have the entire source distribution tree in place (which is currently 
required).  As PostGIS is a separately developed and distributed module, it 
seems reasonable that it should be buildable without the full source tree in 
place. 

As to getting rid of bloat, I'm all for splitting out contrib modules, client 
libraries, and the like into separate projects.  If the build system is a 
unit, and is not dependent upon the server or libpq source code, then it is 
easier and more consistent to just require it to be in place to build ANY 
contrib or client module.

We're too big and too spread out.  It was said (by Andrew) that we're hard to 
install -- why is that?  Is it possible that it is _because_ of the number of 
pieces we include?

And the sooner our very old perl client goes away, the better I like it.  It 
is a good client, don't get me wrong: but DBD:Pg is the standard now.

But, if you are an RPM user, you can already just download the pieces for a 
minimal client-side system.  And you have been able to do so for right at 
three years, give or take.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11