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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
