Re: Trimming the Fat, Part Deux ...

On Thursday 01 August 2002 05:22 pm, Bruce Momjian wrote:
> Lamar Owen wrote:
> > It's already in CPAN. A link to CPAN should suffice, IMHO.

> > I also thought we were discussing trimming the tree; and that was a good
> > feeling.

> Lamar, you said earlier today:
> > 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.

> So I assumed you wanted DBD:Pg.

I'm sorry I gave that impression; I was advocating removing the old Pg module
in favor of people using the DBD::Pg module, which is distributed separately
in CPAN. I wasn't advocating bringing DBD::Pg into our distribution; my
apologies for giving the wrong impression.

DBD::Pg is typically distributed separately even in things such as Red Hat
Linux, where it lives as a separate RPM. There's also qt-PostgreSQL,
php-pgsql, mod_auth_pgsql, and others that are doing quite OK outside our
CVS. The OpenACS/AOLserver PostgreSQL driver is a good example of a client
outside our CVS that is being very well maintained by its group.

We should be providing the core client library, the backend, and
documentation. Contrib modules (earthdistance, etc), other clients, and
things that don't fit in the core should be separately tarballed -- not
necessarily separately CVS'd -- the AOLserver CVS, for instance, has a number
of modules, all of which are somewhat independent.

Those modules then need to be buildable with a set of headers and makefile
includes ONLY. Without assuming any paths.

> DBD:Pg is a good example of an
> interface that hasn't advanced a quickly as it would have had it been in
> our CVS tree. I have received a number of bug reports for it, and have
> them in my mailbox. I have no idea if they made it into the CPAN
> version. Moving interfaces out can be a problem too unless there is a
> large enough group to grow it.

Even if it's in a CVS at postgresql.org it doesn't necessarily need to be in
the main tarball. Even stuff in our CVS can languish -- witness the pgaccess
revival outside the CVS tree.

The main tarball needs dramatic splitting into independent pieces, with a
build framework that can deal with the pieces. If I want a perl client, the
backend, and PostGIS, I should be able to download the build system, the perl
client, the backend, and PostGIS and make it work. And each module shouldn't
require the source of the other modules to build -- just the necessary bits
in headers. If I want just the python client, I should be able to download
the client-side development headers, configure, and makefile, then download
the python client, and build it.

And if I already have headers installed as part of a RPM or from source, I
shouldn't need config.guess, configure, makefile.global, or anything but a
set of C headers to get the python client to build. IOW the python client
should be somewhat independent.

It CAN be done -- the AOLServer/OpenACS PostgreSQL driver does it -- all it
needs is the path to the headers and to libpq and it's off to the races.

I guess I'm saying that we're too big and too popular to include the kitchen
sink in the tarball anymore. We need to think more modularly -- and not
assume a source tree with those modules.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11