Re: deb package sizes

On 9/1/25 18:08, Jeremy Schneider wrote:
> On Thu, 9 Jan 2025 17:06:57 +0100
> Álvaro Hernández<aht(at)ongres(dot)com> 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