Re: Why not install pgstattuple by default? - Mailing list pgsql-hackers

Christopher Browne <cbbrowne@gmail.com> writes:
> But people are evidently still setting packaging policies based on how
> things were back in 7.3, even though that perhaps isn't necessary
> anymore.

FWIW, once you get past the client versus server distinction, I think
most subpackaging decisions are based on either the idea that "only a
minority of people will want this", or a desire to limit how many
dependencies are pulled in by the main package(s).  Both of those
concerns apply to various subsets of -contrib, which means it's going
to be hard to persuade packagers to fold -contrib into the -server
package altogether.  Nor would you gain their approval by trying to
pre-empt the decision.

We might get somewhere by trying to identify a small set of particularly
popular contrib modules that don't add any extra dependencies, and then
recommending to packagers that those ones get bundled into the main
server package.

> Certainly it's not a huge amount of code; less than 2MB these days.
> -> % wc `dpkg -L postgresql-contrib-9.0` | tail -1
>   15952   67555 1770987 total

Well, to add some concrete facts rather than generalities to my own post,
here are the sizes of the built RPMs from my last build for Fedora:

-rw-r--r--. 1 tgl tgl  3839458 Apr 18 10:50 postgresql-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl   490788 Apr 18 10:50 postgresql-contrib-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl 27337677 Apr 18 10:51 postgresql-debuginfo-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl   961660 Apr 18 10:50 postgresql-devel-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl  7569048 Apr 18 10:50 postgresql-docs-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl   246506 Apr 18 10:50 postgresql-libs-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl    64940 Apr 18 10:50 postgresql-plperl-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl    65776 Apr 18 10:50 postgresql-plpython-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl    45941 Apr 18 10:50 postgresql-pltcl-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl  5302117 Apr 18 10:50 postgresql-server-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl  1370509 Apr 18 10:50 postgresql-test-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl  3644113 Apr 18 10:50 postgresql-upgrade-9.0.4-1.fc13.x86_64.rpm

The separate debuginfo package is distro policy enforced by toolchain;
I couldn't do anything about that even if I wanted to.  The separate
-libs subpackage is also hard to avoid because of distro policy about
multilib installations.  Separating devel support files (such as
headers) is also standard practice.  The other subdivisions are either
my fault or those of my predecessors.  plperl, plpython, and pltcl are
split out for dependency reasons, ie to not have the -server package
require you to install those languages and their respective ecosystems.
I think the separation of the -docs, -test, and -upgrade subpackages is
also pretty easy to defend on the grounds that "they're big and not
everyone wants 'em, especially not in production".

That leaves us with these three subpackages about which there's room
for argument:

-rw-r--r--. 1 tgl tgl  3839458 Apr 18 10:50 postgresql-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl   490788 Apr 18 10:50 postgresql-contrib-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl  5302117 Apr 18 10:50 postgresql-server-9.0.4-1.fc13.x86_64.rpm

Merging -contrib into the server package would increase the size of the
latter by almost 10%, which is enough to bother people.  Also, a bit of
dependency extraction shows that -contrib has these dependencies beyond
the ones in the two main packages:

libcrypt.so.1
libossp-uuid.so.16
libxslt.so.1

That's not a particularly large list, I guess, but they're still the
sorts of dependencies that don't win any friends when it's time to get
the distro to fit on a DVD.

Bottom line is that I'd rather have a smaller postgresql-server package
that gets included in the shipping DVD than a complete one that gets
kicked off because it's too large and pulls in too many other non-core
dependencies.

So, again, some selective migration of contrib modules into the main
-server package might be doable, but the key word there is selective.
        regards, tom lane