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

On Sat, 11 Jan 2025 13:14:29 -0800
Jeremy Schneider <schneider(at)ardentperf(dot)com> wrote:

> On Sat, 11 Jan 2025 22:08:02 +0100
> Christoph Berg <cb(at)df7cb(dot)de> wrote:
>
> > Re: Jeremy Schneider
> > > 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.
> >
> > You are missing the fact that postgresql-common is written in perl.
> >
>
> 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

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