Re: deb package sizes

On Thu, Jan 9, 2025 at 11:40 PM Álvaro Hernández <aht(at)ongres(dot)com> wrote:

>
>
> 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> <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.
>

I'm guessing most container builders are just not interested in doing that
much work. It's easier to just "always upgrade", but as noted that comes
with a whole different set of problems. It's only really feasible if you
manage to first reduce the set of dependencies substantially.

>
> 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.
>

Debian (as this was talking about it) is actually doing a very good job ot
that these days, though they're not there all the way. But
https://tests.reproducible-builds.org/debian/reproducible.htmlshows they're
doing really well.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>