On 5/22/06, Mark Woodward <pgsql@mohawksoft.com> wrote:
> > Except that apt doesn't work on all platforms. Though it would certainly
> > make sense to look at lifting the framework for CPgAN from somewhere,
> > rather than coding it ourselves.
>
> A CPgAN would be a great idea in theory, but I have reservations.
>
> As a software developer, I'm fine with pgfoundery, but as a DB admin, and
> one who deploys data centers from time to time, I'd like to see something
> closer to the contrib.
>
> If I could have any influence at all, I'd like to see "contrib"
> essentially go away in the main distribution and replaced or renamed
> "extensions." Then, some advisory group "blesses" extensions, and those
> extensions get packaged into a PostgreSQL extensions pack. I, again as a
> DB admin, would have NO problem with PostgreSQL playing favorites and
> picking best of breed for these extensions.
The "problem" with contrib is that no actively developed projects should
be there. It is a feature, not a bug. If it is actively developed, it may be
buggy. If it is proven over time, it can be safely used. Also, for a contrib
it is inefficient to release a whole -contrib whenever a subproject releases
new release. This "forces" -contrib to use stable-and-unchanging packages.
This also makes it extremaly hard to put new or niche projects. New are
risky, because they may need immediate bugfixes. Niche projects used
by a minority of users bloat -contrib and force more frequent releases,
both of which are well, not preferred.
Of course -contrib is great, we all know it. I think a "CPgAN" would be
a good testbed/incubator for new packages, some of which should
eventually get into -contrib.
Also, assuming there is a "pginstall dbanme packagename" interface,
a -contrib package should register all its subpackages within that
system. So, you install postgresql-contrib, and then you can type:
pg_package install mydb index/ltree
and later, provided you change your mind:
pg_package remove mydb index/ltree
(with -f option to "insert CASCADE whenever possible ;)).
This would be somewhat similar to current createlang(1) and friends. :)
Regards,
Dawid