MIME-Version: 1.0
References: <20250109005301.3b145092@jeremy-ThinkPad-T430s>
 <Z3-RzHXhWeQkSFU7@msg.df7cb.de>
 <bf542776-4c08-403b-9353-ed2bb3579589@ongres.com>
 <20250109090845.24e1df6e@jeremy-ThinkPad-T430s>
 <bc8a4c35-7190-48f0-aa7c-f816cf9b0615@ongres.com>
In-Reply-To: <bc8a4c35-7190-48f0-aa7c-f816cf9b0615@ongres.com>
From: Magnus Hagander <magnus@hagander.net>
Date: Fri, 10 Jan 2025 10:52:44 +0100
Message-ID: 
 <CABUevEzt5sF7tcn6=WVW8PTCfrf9qzmHicxN3mt37Th1kwfZHQ@mail.gmail.com>
Subject: Re: deb package sizes
To: =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6?= <aht@ongres.com>
Cc: Jeremy Schneider <schneider@ardentperf.com>,
 Christoph Berg <myon@debian.org>,
	pgsql-pkg-debian@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000002005c1062b570f5f"
Archived-At: 
 <https://www.postgresql.org/message-id/CABUevEzt5sF7tcn6%3DWVW8PTCfrf9qzmHicxN3mt37Th1kwfZHQ%40mail.gmail.com>
Precedence: bulk

--0000000000002005c1062b570f5f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 9, 2025 at 11:40=E2=80=AFPM =C3=81lvaro Hern=C3=A1ndez <aht@ong=
res.com> wrote:

>
>
> On 9/1/25 18:08, Jeremy Schneider wrote:
>
> On Thu, 9 Jan 2025 17:06:57 +0100
> =C3=81lvaro Hern=C3=A1ndez <aht@ongres.com> <aht@ongres.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.


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

--0000000000002005c1062b570f5f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jan 9, 2025 at 11:40=E2=80=AFPM =
=C3=81lvaro Hern=C3=A1ndez &lt;<a href=3D"mailto:aht@ongres.com">aht@ongres=
.com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

 =20
   =20
 =20
  <div>
    <br>
    <br>
    <div>On 9/1/25 18:08, Jeremy Schneider
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>On Thu, 9 Jan 2025 17:06:57 +0100
=C3=81lvaro Hern=C3=A1ndez <a href=3D"mailto:aht@ongres.com" target=3D"_bla=
nk">&lt;aht@ongres.com&gt;</a> wrote:

</pre>
      <blockquote type=3D"cite">
        <pre>On 9/1/25 10:07, Christoph Berg wrote:
</pre>
        <blockquote type=3D"cite">
          <pre>Re: Jeremy Schneider =20
</pre>
          <blockquote type=3D"cite">
            <pre>I&#39;m wondering if there might be any support for provid=
ing a
&quot;postgresql-slim&quot; 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.
=20
</pre>
          </blockquote>
          <pre>Hi,

could you explain why 250 MB is too much? Disk space these days is
ultra cheap =20
</pre>
        </blockquote>
        <pre> =C2=A0=C2=A0=C2=A0 Hi Christoph.

 =C2=A0=C2=A0=C2=A0 Container images allow (are meant to) contain only the =
necessary=20
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
</pre>
      </blockquote>
      <pre>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&#39;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.</pre>
    </blockquote>
    <br>
    =C2=A0=C2=A0=C2=A0 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&#39;t seen too many
    examples of taking the effort to do this. But it&#39;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.<br></div></blockquote><div><br></div><=
div>I&#39;m guessing most container builders are just not interested in doi=
ng that much work. It&#39;s easier to just &quot;always upgrade&quot;, but =
as noted that comes with a whole different set of problems. It&#39;s only r=
eally feasible if you manage to first reduce the set of dependencies substa=
ntially.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div>
    <br>
    =C2=A0=C2=A0=C2=A0 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.<br></div></blockquote><div><br></div><div>Debian =
(as this was talking about it) is actually doing a very good job ot that th=
ese days, though they&#39;re not there all the way. But=C2=A0<a href=3D"htt=
ps://tests.reproducible-builds.org/debian/reproducible.htmlshows">https://t=
ests.reproducible-builds.org/debian/reproducible.htmlshows</a> they&#39;re =
doing really well.=C2=A0</div><div><br></div><div><br></div></div><span cla=
ss=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail=
_signature"><div dir=3D"ltr"><div>=C2=A0Magnus Hagander<br>=C2=A0Me: <a hre=
f=3D"http://www.hagander.net/" target=3D"_blank">https://www.hagander.net/<=
/a><br>=C2=A0Work: <a href=3D"http://www.redpill-linpro.com/" target=3D"_bl=
ank">https://www.redpill-linpro.com/</a></div></div></div></div>

--0000000000002005c1062b570f5f--