public inbox for [email protected]
help / color / mirror / Atom feedFrom: Álvaro Hernández <[email protected]>
To: Jeremy Schneider <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: [email protected]
Subject: Re: deb package sizes
Date: Thu, 9 Jan 2025 23:40:31 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <20250109090845.24e1df6e@jeremy-ThinkPad-T430s>
References: <20250109005301.3b145092@jeremy-ThinkPad-T430s>
<[email protected]>
<[email protected]>
<20250109090845.24e1df6e@jeremy-ThinkPad-T430s>
On 9/1/25 18:08, Jeremy Schneider wrote:
> On Thu, 9 Jan 2025 17:06:57 +0100
> Álvaro Hernández<[email protected]> wrote:
>
>> On 9/1/25 10:07, Christoph Berg wrote:
>>> Re: Jeremy Schneider
>>>> I'm wondering if there might be any support for providing a
>>>> "postgresql-slim" package on PGDG which excludes llvm and python? I
>>>> think this might almost cut the total install size in half, and I
>>>> think there might be many users who would value having the option.
>>>>
>>> Hi,
>>>
>>> could you explain why 250 MB is too much? Disk space these days is
>>> ultra cheap
>> Hi Christoph.
>>
>> Container images allow (are meant to) contain only the necessary
>> files needed to run the process that will be run when the image is
>> run. As such, any additional file poses two main problems:
>>
>> * Disk space is cheap. Bandwidth not so much. Time to start a
>>
>> * Security analysis. Unneeded files (specially binaries, but not
> Another concern is the impact of image rebuilds as dependencies are
> updated. Tianon (a primary maintainer of the docker images) has noted
> that they limit frequency of the debian base containers, because every
> rebuild of the base container triggers an avalance of downstream
> rebuilds. CNPG was doing daily rebuilds for awhile, and every time any
> python dependency was updated you'd get a new image - boto3 was
> notorious for very frequent updates. So with a different image version
> for every day, a single server running multiple copies of postgres might
> easily end up with multiple image versions on the server as copies are
> slowly updated.
I see this as a symptom of a different, bigger issue: that package
versions, and all transitive dependencies, should be version pinned when
building container images. I haven't seen too many examples of taking
the effort to do this. But it's the only way to have a way to re-run
building images and guarantee outputs that are reproducible. Once you
have this in place, you can decide how and when you upgrade which versions.
Actually, even version pinning is not enough, unless the package
system guarantees that a version of a package is strictly immutable (and
AFAIK this is usually not the case). So digest pinning is essentially
required.
> But with ICU there is at least the option that someone could rebuild an
> old version and run it on the new debian release. That's nearly
> impossible with glibc.
>
Exactly, and this is doable.
Álvaro
--
Alvaro Hernandez
-----------
OnGres
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: deb package sizes
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox