Re: moving from contrib to bin

Re: Andres Freund 2014-12-12 <20141212152723(dot)GO31413(at)awork2(dot)anarazel(dot)de>
> On 2014-12-12 10:20:58 -0500, Tom Lane wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > On 12/12/14 8:13 AM, Andres Freund wrote:
> > >> Wouldn't a make install-server/client targets or something similar
> > >> actually achieve the same thing? Seems simpler to maintain to me.

Ack. The default install location would still be .../bin, but invoked
from different targets.

> > > Adding non-standard makefile targets comes with its own set of
> > > maintenance issues.
> >
> > It would be of zero value to packagers anyway; certainly so for those
> > following the Red Hat tradition, in which you tell the package Makefile
> > to install everything and then what goes into which subpackage is
> > sorted out in a separate, subsequent step. Possibly Debian or other
> > packaging infrastructures do it differently, but I doubt that.
>
> Debian has that step as well - you don't really have to use it, but the
> postgres debian packages do so. They already don't adhere to the current
> distinction.

The standard Debian package installs into debian/tmp/ and then picks
files from there into individual packages.

However, for PostgreSQL this means lengthy debian/*.install files
(the equivalent of %files in rpm spec speak):

$ wc -l debian/*.install
2 debian/libecpg6.install
1 debian/libecpg-compat3.install
17 debian/libecpg-dev.install
1 debian/libpgtypes3.install
2 debian/libpq5.install
14 debian/libpq-dev.install
39 debian/postgresql-9.4.install
40 debian/postgresql-client-9.4.install
65 debian/postgresql-contrib-9.4.install
2 debian/postgresql-doc-9.4.install
3 debian/postgresql-plperl-9.4.install
2 debian/postgresql-plpython3-9.4.install
3 debian/postgresql-plpython-9.4.install
5 debian/postgresql-pltcl-9.4.install
3 debian/postgresql-server-dev-9.4.install
199 total

If there were separate "install-client", "install-server", and
"install-contrib" targets, that would probably shorten those files
quite a bit. Especially messy is the part where *.so needs to be
sorted into server/contrib, along with an similar large bunch of
binaries.

Of course that would only solve part of the problem (I'm not going to
suggest creating 15 targets for the 15 binary packages we are
building), but it would solve the uglier part.

Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/