Обсуждение: postgresql-client-common pulling in libipc-run-perl
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
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. Christoph
On Sat, 11 Jan 2025 22:08:02 +0100 Christoph Berg <cb@df7cb.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 -Jeremy
On Sat, 11 Jan 2025 13:14:29 -0800 Jeremy Schneider <schneider@ardentperf.com> wrote: > On Sat, 11 Jan 2025 22:08:02 +0100 > Christoph Berg <cb@df7cb.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