Re: [pgsql-advocacy] Increased company involvement - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [pgsql-advocacy] Increased company involvement
Date
Msg-id 20050506152349.GN30011@ns.snowman.net
Whole thread Raw
In response to Re: [pgsql-advocacy] Increased company involvement  ("Magnus Hagander" <mha@sollentuna.net>)
Responses Re: [pgsql-advocacy] Increased company involvement  ("Marc G. Fournier" <scrappy@postgresql.org>)
List pgsql-hackers
* Magnus Hagander (mha@sollentuna.net) wrote:
> If you are on debian or a derivative, of course. I assume we are not
> planning to abandon the users who build from source.

Not abandon them, no.  That's where Marc's stuff comes into play really,
and the WTKS stuff.

> (won't using apt-get get you a pre-8.0 version, btw? :P)

Not if you're using the Debian/experimental repository. :)

> Why may it need to be done? If the build issue can be solved, I'm sure
> the packaging can be solved at least as easy.

<Shrug>  Because core isn't going to maintain them all forever, not that
it sounds like much is done to maintain them currently anyway...  Also,
as people become aware that it's easier to write PLs for Postgres there
may be more showing up (ruby, for example).

I don't *know* any of this for sure, but it certainly seems like it'll
happen eventually.

> > Perhaps the interfaces are still in alot of flux, but this is
> > actually not exactly unheard of when things start taking off
> > more and more- the big universal package gets split up with
> > well defined interfaces into seperate pieces so that new
> > pieces can be created more easily and maintained in a
> > distributed manner.
>
> In this discussion, I don't care where they are maintained - core cvs,
> separate cvs, etc. I care where they are packaged for download - the
> tar.gz files. They can be maintained elsewhere for all I care (though I
> do see the points of keeping them in there, in order to track API
> changes etc), as long as they are still pulled into the main tarball.
> I'm concerned with making things easy for the *user*. Splitting it up
> may (though I'm not convinved of that part) make it easier for the
> *developer*, but certainly not for the *user*.

The source user- perhaps not.  Then again, the source user may not want
to build every PL, and thus have to have the build requirements for
every PL that's in PostgreSQL.  This starts to become a 'where do you
draw the line' question.  Marc's talking about adding more stuff into
WTKS than you'd like, but why shouldn't they go in there?  Because
they'd add additional build dependencies you don't want to have to
worry about?  What about that person who doesn't want to have to have
PL/Python or Python installed at all?

Honestly, I think WTKS will work for you, though you may end up
downloading more than you want and you'll have to ignore build failures
for those PLs you don't have the interpreters for.  If you want it more
granular than that then you're going to have to download them
individually unless you can come up with a sensible line that Marc
agrees is useful enough to add yet-another tarball for.
Stephen



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: State of Kerberos v4 support
Next
From: "Marc G. Fournier"
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement