pgsql/doc TODO

CVSROOT: /cvsroot
Module name: pgsql
Changes by: momjian(at)postgresql(dot)org 02/02/21 00:10:49

Modified files:
doc : TODO

Log message:
Marc, you get this one. :-) You are the expert on the item:

> * Allow ability to easily build only certain interfaces (Marc)

Peter Eisentraut wrote:
> Bruce Momjian - CVS writes:
>
> > > * Allow ability to easily build only certain interfaces (Marc)
>
> We already have that:
>
> make -C /what/ever install

OK, Marc, can you comment. Is that easy enough? I didn't see that
mentioned in the discussion.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Bruce Momjian - CVS writes:

> > * Allow ability to easily build only certain interfaces (Marc)

We already have that:

make -C /what/ever install

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Bruce Momjian - CVS writes:
> * Allow ability to easily build only certain interfaces (Marc)
> We already have that:
> make -C /what/ever install

The ability is there in theory, but it's not documented very well.
And I think Marc was also complaining about the download time to
pull a full tarball when he only wanted to build client-side code.

Couldn't we construct a package that's just client-side code plus
configure/build support?

regards, tom lane

Tom Lane writes:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Bruce Momjian - CVS writes:
> > * Allow ability to easily build only certain interfaces (Marc)
> > We already have that:
> > make -C /what/ever install
>
> The ability is there in theory, but it's not documented very well.

Right, we could document these things.

> And I think Marc was also complaining about the download time to
> pull a full tarball when he only wanted to build client-side code.

I think Marc's problem was that he was using an inappropriate package
management system. On that other free operating system, you'd simply
download the precompiled postgresql-libs-xxx.rpm and install it on all the
virtual hosts. Marc insisted on using the FreeBSD port system's
compile-from-source approach every time. Instead he could have chosen to
build a FreeBSD binary package (which exist).

> Couldn't we construct a package that's just client-side code plus
> configure/build support?

Not easily, since there are a number of interdependencies between client
and server code. I guess it's possible, but then we're going to have a
big war about exactly which clients are "worthy". Honestly, I don't
believe in the necessity: If you need a client you have to have a server
somewhere, so you already have the code.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Thu, 21 Feb 2002, Tom Lane wrote:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Bruce Momjian - CVS writes:
> > * Allow ability to easily build only certain interfaces (Marc)
> > We already have that:
> > make -C /what/ever install
>
> The ability is there in theory, but it's not documented very well.
> And I think Marc was also complaining about the download time to
> pull a full tarball when he only wanted to build client-side code.
>
> Couldn't we construct a package that's just client-side code plus
> configure/build support?

Correct, that is what I was/am looking for ... I have no qualms about
leaving everything in the one central CVS, but would love to have our
currently 'distribution split' ability extended so that we'd have a:

postgresql-jdbc.tar.gz
postgresql-perl5.tar.gz
postgresql-libpq.tar.gz

tar files split out ... I'd like to be able to download a couple of k tar
file of libpq to install on a client machine, rather then have to download
an 8+ and growing Meg file just for a couple of k worth of files ...

> > Couldn't we construct a package that's just client-side code plus
> > configure/build support?
>
> Not easily, since there are a number of interdependencies between client
> and server code. I guess it's possible, but then we're going to have a
> big war about exactly which clients are "worthy". Honestly, I don't
> believe in the necessity: If you need a client you have to have a server
> somewhere, so you already have the code.

I agree with Peter too. Let's not waste our time.
--
Tatsuo Ishii

Tatsuo Ishii wrote:
> > > Couldn't we construct a package that's just client-side code plus
> > > configure/build support?
> >
> > Not easily, since there are a number of interdependencies between client
> > and server code. I guess it's possible, but then we're going to have a
> > big war about exactly which clients are "worthy". Honestly, I don't
> > believe in the necessity: If you need a client you have to have a server
> > somewhere, so you already have the code.
>
> I agree with Peter too. Let's not waste our time.

OK, TODO updated:

* Better document ability to easily build only certain interfaces (Marc)

If we shipped source for say, libpq, and we shipped all the directories,
mostly empty, and the files that configure modifies, couldn't we make a
libpq-only source distibution?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026