Subject: postgresql-client-common pulling in libipc-run-perl

From: Jeremy Schneider <[email-masked]>
Date: Sat, 11 Jan 2025 12:28:47 -0800

Last week I started digging into docker image sizes, and I noticed that
perl and llvm together make up 44% of the package. My initial email
asked about a "slim" package which might change build flags.

I had thought that the dependencies on llvm and perl were coming from
the postgres server. After some further checking, I realized today that
the postgres server is pulling in llvm, but in fact it's the postgres
client that's pulling in perl. Debian packaging already splits out
plperl into a separate package with a dependency on perl, and the
postgres server package itself does not depend on perl.

Per my previous email, dpkg Installed-Size (without plperl installed):
 libperl5.36   28862 KB
 perl-modules-5.36     17816 KB
 perl  669 KB
 libio-pty-perl        103 KB
 libipc-run-perl       267 KB

Here is a dependency tree, showing how the perl packages are getting
pulled into the docker image:

perl-modules-5.36
├── libperl5.36
└───└── perl
        └── libio-pty-perl
            └── libipc-run-perl
                └── postgresql-client-common
                    ├── postgresql-common
                    │   └── postgresql-17
                    └── postgresql-client-17
                        └── postgresql-17

So the real question is why the client-common package has a hard
requirement on libipc-run-perl, and whether we can make this dependency
optional (or remove it). That would trim about 45MB off the base
container size, which is meaningful since these base images are very
widely used.

For LLVM, after giving it a little more thought, I think the best
solution would actually be to discuss on hackers the idea of making JIT
something more like an extension which can be installed separately
without a recompile, so that it could be split into a separate debian
package - similar to plperl, plpython and pltcl.

-Jeremy

---

From: Christoph Berg <[email-masked]>
Date: Sat, 11 Jan 2025 22:08:02 +0100

Re: Jeremy Schneider
> container size, which is meaningful since these base images are very

You are missing the fact that postgresql-common is written in perl.

Christoph

---

From: Jeremy Schneider <[email-masked]>
Date: Sat, 11 Jan 2025 13:14:29 -0800

On Sat, 11 Jan 2025 22:08:02 +0100
Christoph Berg <[email-masked]> wrote:

> > requirement on libipc-run-perl, and whether we can make this
> > dependency optional (or remove it). That would trim about 45MB off
> > the base container size, which is meaningful since these base
> > images are very widely used.  
> 

lol, yes i sent this email before tracking down what the package is and
what is does and how its written (it looks like a different package from
the postgresql client itself, but its a hard dependency of the client)

i'll go find the code and start reading

-Jeremy

---

From: Jeremy Schneider <[email-masked]>
Date: Sat, 11 Jan 2025 15:05:06 -0800

On Sat, 11 Jan 2025 13:14:29 -0800
Jeremy Schneider <[email-masked]> wrote:

> lol, yes i sent this email before tracking down what the package is
> and what is does and how its written (it looks like a different
> package from the postgresql client itself, but its a hard dependency
> of the client)
> 

i wasn't heavily using postgres debian packages until recently. so i'm
coming up to speed now on the specifics of how the packages are set up.

this is where all those super useful debian postgres management scripts
come from!

https://packages.debian.org/sid/all/postgresql-client-common/filelist

if i'm reading correctly then the upstream source is here, in salsa:

https://salsa.debian.org/postgresql/postgresql-common/-/blob/master/debian/control?ref_type=heads

my first pass (prev email) was using "apt rdepends" and i didn't
realize but apparently that command doesn't show virtual dependencies;
from the control file above i see that both postgresql-client-common
and also postgresql-common have direct deps for perl. "apt depends" also
confirms the dependency.

Depends: <perl:any>
  perl

this makes sense now. it's the whole multiversion/multicluster postgres
management suite that debian has (which i knew about, but haven't used
heavily).

it's interesting how debian has turned out to be such a popular "base
image" on which to build containers. i think that Docker Inc's open
source 74MB "slim" debian base containers images are helping this.

in my case, i'm working with postgres on kubernetes with a fully open
source stack. at present i don't think the operator i'm using depends on
any of the debian multiversion/multicluster (postgres-common) code. so
it seems for now we just pay this 45MB tax in exchange for working in
the debian ecosystem. the benefit is not just prebuilt postgres for our
container builds, but also every extension which is packaged for debian
today.

maybe some kind of option for postgres debian packages without the
multiversion/multicluster scripts will evolve, but i don't think it's
as easy as i hoped, and the 45MB tax is tolerable in the near term as a
tradeoff for access to the ecosystem.

i'm still curious about whether LLVM/JIT can easily be split out into a
recommended/optional separate debian package. i asked on the hackers
list about this and Tom Lane replied [1]:

> Alternatively, split lib/llvmjit.so and lib/bitcode/ into a separate
> package.  

but i'm not sure if he was just giving a quick reply, and whether he
fully thought through whether you can get errors/problems by building
postgres with these libraries and then running it without them. i
should give that a try. if it results in errors because postgres
expects libraries to be there and tries to JIT some queries, then we'd
need core work before we could try this packaging change.

-Jeremy

1: https://postgr.es/m/153692.1736630059%40sss.pgh.pa.us