Re: modules - Mailing list pgsql-hackers

From Ron Mayer
Subject Re: modules
Date
Msg-id 47F50645.8070303@cheapcomplexdevices.com
Whole thread Raw
In response to Re: modules  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Responses Re: modules  ("D'Arcy J.M. Cain" <darcy@druid.net>)
List pgsql-hackers
D'Arcy J.M. Cain wrote:

> Check out NetBSD pkgsrc as a model.  It is very flexible.  One nice
> thing would be the ability to specify where the packages are rather
> than always insisting that they be on pgfoundry.

Yup - a feature shared by RubyGems:  gem install rails –source http://gems.rubyonrails.org

Many of the most popular modules seem to live outside of
pgfoundry anyway (postgis, the contrib ones, etc); so I'd
think even if we maintain a central repository we want to
make sure it can install from other sites.


>> Perl and Ruby are languages - Postgres is a very different animal.
> 
> ...Overall though
> I don't think that what is being installed to changes much.  The basics
> remain the same - define the package with latest version, download if
> necessary,check that the source package is the correct, tested one,
> build, install, register.

+1.   From the end user I think he cares that the software is installed
with the required dependencies and passes any included regression tests.
Bonus points if it also registers itself in his database.

And in the ruby/gems world the Windows guys seem not to have liked
the "check...source packages...build" so they include precompiled
windows libraries for those guys in many Ruby Gems.



pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: [GENERAL] SHA1 on postgres 8.3
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong