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