On Apr 3, 2008, at 7:01 AM, Aidan Van Dyk wrote:
> * Greg Sabino Mullane <greg@turnstep.com> [080403 09:54]:
>
>> Right now contrib is a real catch-all of various things; it would
>> be nice to
>> categorize them somehow. And by categorize, I emphatically do NOT
>> mean
>> move to pgfoundry, which is pretty much a kiss of death.
>
> But that begs the question of *why* it's a kiss of death?
>
> For instance, in "perl land", having something in "CPAN" and not in
> "perl core" is most certainly *not* a kiss of death? Why is it so
> different for PostgreSQL?
>
> Is it because the infrastructure behind CPAN is much better than that
> behind pgfoundry?
Yes. I can install a package from a CPAN mirror with a one-line
incantation and be sufficiently sure it works that on the very rare
occasions it doesn't I'm really surprised.
On the Windows end of things I can usually get pre-built binaries
of those same packages installed, in the cases where a compiler
is needed to build them. The exact process is a bit different, but it's
consistent across most packages and uses the same namespace.
> Or is it because CPAN is better "vetted" and "organized" than
> pgfoundry?
Partly. "Vetted" is partly self-vetting - you're expected to pass your
self
tests and install cleanly before you publish to CPAN. The naming
hierarchy
helps with the CPAN organization, and makes it easier to use than the
trove approach, once you're familiar with the perl namespace habits.
Some of that is applicable to a postgresql package distribution method,
but the neat organization is a perl thing, not a CPAN thing, so that
idea
doesn't really transfer.
>
>
> Or is it because the projects that go into CPAN are better quality and
> projects in pgroundry?
Partly. There are some dubious packages on CPAN but they're finished,
and with extremely few exceptions download, pass their self tests and
do what it says on the box (the main flaws are packages going stale
and occasionally dependency problems).
Pgfoundry is a development site with a search engine and has projects
in various stages of completion from vaporware to production tested
usable code.
> Or is it something else?
Projects vs Packages sums up the differences.
Cheers, Steve
