Thread: Re: [pgsql-advocacy] Increased company involvement

> > Remind me again how this is actually *better*, and not just making
> > life a whole lot worse for me? And more specifically, for a
> new user
> > that doesn't know which files to download already, and will
> just grab
> > the default file.
>
> Or the new user will go 'apt-get install postgresql' and have
> all the various packages downloaded and installed for them.
> Alternatively, if they only *want* the server and not every
> PL under the moon, with all the various dependencies that may
> involve, then can 'apt-get install postgresql-server'.  Big
> win for me.

If you are on debian or a derivative, of course. I assume we are not
planning to abandon the users who build from source.
(won't using apt-get get you a pre-8.0 version, btw? :P)


> > Pulling the interfaces out of the main tarball was bad
> enough, but it
> > had point - ODBC and JDBC need to work with different versions, and
> > may be released as different times. Please don't do the
> same for PLs.
>
> It may need to be done for PLs in the end, especially as more
> and more are done (which may happen once it's made easier to
> do, and examples are available, and something that anyone
> could do on their own and provide a sensible build for, since
> it doesn't have to be in the main build tree).

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.


> 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*.

//Magnus

* 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

On Fri, 6 May 2005, Stephen Frost wrote:

> 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.

Actually, that shouldn't be an issue ... the WTKS tar ball would have a 
configure like we have now:

./configure --with-python

so that you could pick-n-choose which ones to build ... or, rather, it 
should be smarter yet and be able to determine that libpython is available 
or not, and build accordingly ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664