public inbox for [email protected]
help / color / mirror / Atom feedpostgresql-client-common pulling in libipc-run-perl
4+ messages / 2 participants
[nested] [flat]
* postgresql-client-common pulling in libipc-run-perl
@ 2025-01-11 20:28 Jeremy Schneider <[email protected]>
2025-01-11 21:08 ` Re: postgresql-client-common pulling in libipc-run-perl Christoph Berg <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Jeremy Schneider @ 2025-01-11 20:28 UTC (permalink / raw)
To: [email protected] <[email protected]>
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: postgresql-client-common pulling in libipc-run-perl
2025-01-11 20:28 postgresql-client-common pulling in libipc-run-perl Jeremy Schneider <[email protected]>
@ 2025-01-11 21:08 ` Christoph Berg <[email protected]>
2025-01-11 21:14 ` Re: postgresql-client-common pulling in libipc-run-perl Jeremy Schneider <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Berg @ 2025-01-11 21:08 UTC (permalink / raw)
To: Jeremy Schneider <[email protected]>; +Cc: [email protected] <[email protected]>
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: postgresql-client-common pulling in libipc-run-perl
2025-01-11 20:28 postgresql-client-common pulling in libipc-run-perl Jeremy Schneider <[email protected]>
2025-01-11 21:08 ` Re: postgresql-client-common pulling in libipc-run-perl Christoph Berg <[email protected]>
@ 2025-01-11 21:14 ` Jeremy Schneider <[email protected]>
2025-01-11 23:05 ` Re: postgresql-client-common pulling in libipc-run-perl Jeremy Schneider <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Jeremy Schneider @ 2025-01-11 21:14 UTC (permalink / raw)
To: Christoph Berg <[email protected]>; +Cc: [email protected] <[email protected]>
On Sat, 11 Jan 2025 22:08:02 +0100
Christoph Berg <[email protected]> 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: postgresql-client-common pulling in libipc-run-perl
2025-01-11 20:28 postgresql-client-common pulling in libipc-run-perl Jeremy Schneider <[email protected]>
2025-01-11 21:08 ` Re: postgresql-client-common pulling in libipc-run-perl Christoph Berg <[email protected]>
2025-01-11 21:14 ` Re: postgresql-client-common pulling in libipc-run-perl Jeremy Schneider <[email protected]>
@ 2025-01-11 23:05 ` Jeremy Schneider <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Jeremy Schneider @ 2025-01-11 23:05 UTC (permalink / raw)
To: Christoph Berg <[email protected]>; +Cc: [email protected] <[email protected]>
On Sat, 11 Jan 2025 13:14:29 -0800
Jeremy Schneider <[email protected]> wrote:
> On Sat, 11 Jan 2025 22:08:02 +0100
> Christoph Berg <[email protected]> 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
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2025-01-11 23:05 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-01-11 20:28 postgresql-client-common pulling in libipc-run-perl Jeremy Schneider <[email protected]>
2025-01-11 21:08 ` Christoph Berg <[email protected]>
2025-01-11 21:14 ` Jeremy Schneider <[email protected]>
2025-01-11 23:05 ` Jeremy Schneider <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox