Re: contrib vs. gborg/pgfoundry for replication solutions

Josh Berkus wrote:
> We can't have *everything* in contrib -- the top 5 GUIs alone would triple the
> size of our downloads. So we need to move in the opposite direction --
> putting more stuff in pgFoundry, and letting packagers know that they should
> package and include all "mature" projects on pgFoundry if they can. (our
> earlier discussion proved that this list cannot realistically designate
> "approved" vs. "unapproved" projects).
>

As I've said on other parts of this thread, my concern with moving
everything to gborg/pgFoundry is that it raises the bar in terms of
difficulty if we expect every individual project to develop their own
infrastructure. What we need to really make that work is to provide an
infrastructure similar to Perl's CPAN or the R project's CRAN. Imagine
how nice it would be if a relatively new Postgres user could do
something like this at a shell prompt:

pgFoundry install slony1
pgFoundry install plr
pgFoundry install tsearch2

That command would go to a standard URL (but maybe overridden by a
configuration option, say to look at a specific mirror, maybe even with
backup mirrors specified too) to grab a tarball, download it, untar it
to some specific location locally, then run make, make install, make
installcheck. The configuration information for the local Postgres
install would need to be handy somewhere, support for installcheck,
along with all headers (I'd think). I don't know all the details
required to make this work, but it would be very useful. Thoughts?

Joe