Thread: Re: [pgsql-advocacy] Increased company involvement
> > Actually, if the number of "split files" (whatever their names) > > increase even further, may I suggest they are moved into a > subdir of > > their own, keeping just the main distribution and the > README about the > > splits in the main dir? > > the "main distribution" will just be > postgresql-server-<release>.tar.gz > ... Ok. Then I definitly change my stand from "indifferent" to "strongly against". > >> postgresql-WTKS.tar.gz (with the kitchen sink) file > that contained > >> everything for those that really wanted to download "it all" ... > > > > That would be "postgresql-x.y.z.tar.gz", right? ;-) > > Nope, postgresql-x.y.z.tar.gz will just be the core > distribution ...the WTKS will be the 'with the kitchen sink' > meta distribution and would be in the subdir that you propose > above ... in fact, I doubt that the WTKS will even be ready > for the next release, as it will involve alot of work on the > build system itself, I would think ... the 'cascading > configure's could be interesting in itself ... Please. *Nobody* will know what postgresql-wkts-x.y.z.tar.gz is. It's hard enough to understand the splits as they are now (what really is in -opt for example? I know it's in the readme, but users don't read that), and this will certainly not make it easier. And please absolutely do *NOT* rip anything out of the main one until the replacement is ready! > > Bottom line - make it easy for the *newbies*. Those of us who know > > exactly what we want will know where to look for it (say in > a separate > > subdir). (or we'll just download the whole tarball anyway > because that > > is *way* much more convenient... Speaking for myself there, of > > course.) > > Note that "the whole tar ball" will give you the core server > and that is it ... the WTKS is a whole seperate project from > what is being planned ... > > What is being worked on right now is effectively reducing > things down to: > > postgresql-server (including libpq) > postgresql-<insert add on here> Um. So instead of as I do today: wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-8.0.2.tar.bz2 tar xjf postgresql-8.0.2.tar.bz2 ./configure --with-perl --with-python --with-tcl gmake && gmake install I'll now have to do: wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-docs-8.0.2.tar.bz2 tar xjf postgresql-docs-8.0.2.tar.bz2 ./configure gmake && gmake install wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-test-8.0.2.tar.bz2 tar xjf postgresql-test-8.0.2.tar.bz2 ./configure gmake && gmake install wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-plperl-8.0.2.tar.bz2 tar xjf postgresql-plperl-8.0.2.tar.bz2 ./configure gmake && gmake install wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-plpython-8.0.2.tar.bz2 tar xjf postgresql-plpython-8.0.2.tar.bz2 ./configure gmake && gmake install wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-pltcl-8.0.2.tar.bz2 tar xjf postgresql-pltcl-8.0.2.tar.bz2 ./configure gmake && gmake install 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. 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. //Magnus
On 5/6/05, Magnus Hagander <mha@sollentuna.net> wrote: > > > Actually, if the number of "split files" (whatever their names) > > > > >> postgresql-WTKS.tar.gz (with the kitchen sink) file > > that contained > > >> everything for those that really wanted to download "it all" ... > > > > > > That would be "postgresql-x.y.z.tar.gz", right? ;-) > > > > Nope, postgresql-x.y.z.tar.gz will just be the core > > distribution ...the WTKS will be the 'with the kitchen sink' > > meta distribution and would be in the subdir that you propose > > above ... in fact, I doubt that the WTKS will even be ready > > for the next release, as it will involve alot of work on the > > build system itself, I would think ... the 'cascading > > configure's could be interesting in itself ... > > Please. *Nobody* will know what postgresql-wkts-x.y.z.tar.gz is. It's > hard enough to understand the splits as they are now (what really is in > -opt for example? I know it's in the readme, but users don't read that), > and this will certainly not make it easier. Hello, If I understood correctly, this 'wtks' distribution will contain what is now in the postgresql-?.?.?.tar.gz , plus other additional things like additional PLs ( which now have to be downloaded and compiled separately ) ? Seems to be a great idea , but i agree that the contents of the postgresql-?.?.?.tar.gz tarballs should not be reduced ! Once this 'wtks' will be available, I bet that most people who are aware of its existance will prefer to download it because it would be much more convenient. The name of the package will need to be carefully chosen, though. "wtks" does not seem to be a good choice ( native English speakers surely know what is a 'kitchen sink', but I really don't understand what it means) . Just wondering: would it be feasible to expand the existing contrib directory to a system similar to the BSD ports collection ? One would type: cd postgresql-8.1.0/contrib/pls/pljava make install ( which would download the pljava sources from pgfoundry, build it and install ) With such a system in place, various modules could be installed in a unique manner no matter where they are hosted. And they would gain visibility ... Best wishes, Adrian Maier > > > Bottom line - make it easy for the *newbies*. Those of us who know > > > exactly what we want will know where to look for it (say in > > a separate > > > subdir). (or we'll just download the whole tarball anyway > > because that > > > is *way* much more convenient... Speaking for myself there, of > > > course.) > > > > Note that "the whole tar ball" will give you the core server > > and that is it ... the WTKS is a whole seperate project from > > what is being planned ... > > > > What is being worked on right now is effectively reducing > > things down to: > > > > postgresql-server (including libpq) > > postgresql-<insert add on here> > > Um. So instead of as I do today: > wget > http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po > stgresql-8.0.2.tar.bz2 > tar xjf postgresql-8.0.2.tar.bz2 > ./configure --with-perl --with-python --with-tcl > gmake && gmake install > > I'll now have to do: > wget > http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po > stgresql-docs-8.0.2.tar.bz2 > tar xjf postgresql-docs-8.0.2.tar.bz2 > ./configure > gmake && gmake install > > 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. > > 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.
* Magnus Hagander (mha@sollentuna.net) wrote:
> 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.
> 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).
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.
Thanks,
Stephen
* Adrian Maier (adrian.maier@gmail.com) wrote:
> Once this 'wtks' will be available, I bet that most people who are
> aware of its existance will prefer to download it because it would
> be much more convenient. The name of the package will need
> to be carefully chosen, though. "wtks" does not seem to be a good
> choice ( native English speakers surely know what is a 'kitchen sink',
> but I really don't understand what it means) .
Much more convenient for an end user who *wants* all of the PLs, and
already has all of the various build dependencies available on their
system, which, btw, I expect more will probably be added, and is
building from source. Certainly not more convenient for the user using
a binary distribution- rather a headache if they *don't* want to
install every language interpreter that someone's made into a PL for
Postgres.
> Just wondering: would it be feasible to expand the existing contrib
> directory to a system similar to the BSD ports collection ?
> One would type:
> cd postgresql-8.1.0/contrib/pls/pljava
> make install
> ( which would download the pljava sources from pgfoundry,
> build it and install )
>
> With such a system in place, various modules could be installed
> in a unique manner no matter where they are hosted. And they
> would gain visibility ...
This seems a great deal like what's under discussion already, except
that it wouldn't be under the postgresql-8.1.0 source directory but
rather in a seperate module. I don't really see much difference between
what you're suggesting and what's being proposed.
Thanks,
Stephen