Content-Type: multipart/alternative;
 boundary="------------0iJhFZEQOxKPANKWK0adgnZ0"
Message-ID: <46ef3419-5a67-4d41-95c2-1cb5db8f4d5a@ongres.com>
Date: Fri, 10 Jan 2025 12:32:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: deb package sizes
To: Magnus Hagander <magnus@hagander.net>
Cc: Jeremy Schneider <schneider@ardentperf.com>,
 Christoph Berg <myon@debian.org>, pgsql-pkg-debian@lists.postgresql.org
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>
 <CABUevEzt5sF7tcn6=WVW8PTCfrf9qzmHicxN3mt37Th1kwfZHQ@mail.gmail.com>
Content-Language: en-US
From: =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6?= <aht@ongres.com>
Autocrypt: addr=aht@ongres.com; keydata=
 xsFNBF8HXQQBEACnRGsBas+BUNQkdN0O0qqfjL/G78gxAI2/6pTLsvXOmA0a6A+o16HynaBc
 PYgWeMrPj3fAlHQ4dyw2CF++LKRmr0xx04GaSi3bijCutRiyFFpdvl2VVRWlYmQhrfS4dVRl
 2cHn+umoj9DOf0DpPYLyB/tHZIaBz1TU/69/7qD3G4NaAI2uGCji2pBNI1TEhOGXPE7HHGxJ
 k4Paf4Dby3VVeufcsTPa006kXj/aEObinpE41Yl/UgeQbnnPazHPXrFyfWpPqw6+kz7Tb+19
 sOGJJAJplVmyqZ2Mewf1RtGOsBD8JABpdzLtv+FxKumnMcEYHLFgD6EQQQZiygg/wUQdXZll
 mvvxlI5VKjxHPnfPvqM44vhWSVPZicH4lWHHXPipesan+7Qg5lVjTnJZHpA6qJtddlNESFKf
 XHm7hzRgOyFuFwU2MABVjQv1noMJqOtM+SaSprEOwt4azanK/CUYQtjNKvAqxOv+YDQ6mWnF
 +Ly97BqSu/xufPzriEL7Qz/tY4Hj4nZAxtud+txhO8LCvu4NsXZUbiuMYgKzxmG9fUFkEAyL
 btBvveH0vzH0wO10lVq0MNeVWTREfRQ8bLjxj5h0pCz65x6+bdtpO0pQXmV1w0hFvwxobRHt
 JubEKLiDPktJ5jHVsa+JqP34SxHm6e9TKG2EQJVlz03RU7g4tQARAQABzTZBbHZhcm8gSGVy
 bmFuZGV6IChPbkdyZXMgR1BHIGFjY291bnQpIDxhaHRAb25ncmVzLmNvbT7CwY4EEwEKADgW
 IQTZ+rL52ABbxJPBTt4qF9KKhgviwwUCXwddBAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIX
 gAAKCRAqF9KKhgviw7WED/44JVShqBCxbSRceu6TOR/H391tAvfyHsAV9vplA7qaqabppqC8
 rWL7t6Ngs53473TgPD+fUDo2gS/8c+TKmJGaGVnbXmFBrEB941nJ2r9Y97NtDXs3j7N7Ed4o
 nr7p01S8Q3BTIWb5tUYa+EkUFOMozPfN3OKStWPhonXADuDv6lZhmw6XkaZ5UHaf4Oj3HGeM
 0KyKWzcVzs47d3Gvi6xjeKOK3VjGNrLKeqO/Ebs8m/WpFSc73s4EbiX9141rcTpHBKzETToE
 wC85hXYNcVF+Is9SFBAbiC05gA4f+4IZK9W+C4o4cRWOlSCE2imgD375JKStaFi158HGL/uG
 8sH1ttnG1vjLUQFE694qHOUXTMUjpyiJPsZLf98LTXSawI35tFV0JwBnwPCYvIn7Bavame17
 fpszGQraXKqQKhBB+rAaHkiDTeYnFlR5St13yhbwwR7JfuHZJ4LvKbCbTxgWhNHH97k+6p9v
 cYo4cvcqgbzWG8TPDCZVR4syqfdDlpYS0YCjv2p/JkJ/rjMoopqroGYHOsNa4bltGri0e2Ms
 L72DQ4qDDqat9QQlgUIUeHB7wYlVTqy1s3z0etAHNCfV86LjcBIbx9ZIx4ztQsCkVCaKFAcX
 HZqBlo/3O4Xo9ULWYT5SCH7XXfXADxblsSRqTDAACWf/86EpwDMVHMOl6M7BTQRfB10EARAA
 uWfs9X2szukOUjFRCuwJgkVKByY8j2i4C4b4/aQF1dJqjo5Ucf16HzDv7LJJgVIEA0XTjuon
 1EelvdIcFR1cjO2b1j8k/tUc8eG0SCr/DfhbYBHllFLTT3CMNuwqqxPJ1/8HlNWrrZreloli
 /wKu5Mq2XKYkvGj/jWnUpW/nzRQJK+uQYNgNsSdcEeQUFcj0NCs3nRNsz/Av9lfMbcKL3ndE
 vYIid9KL3cT65tuwO6/x6dgTsT84tdDqqOCCuu2bfltXP4wFtXVGvTC43UpMhEO2VDNCiM19
 iihwsXJoG6dHgbh8ozINbMrmZyS68h+ITuiaFc1a7JrlXdxnMedGoIsQX0jKbYuNQEP66ovg
 3gGq5TGJ+/2TvytcVHqu0mHV382z5/2duaYyTzlvTaMu9snBW5ACBn1WVguzSn1RiTBvvbd2
 kKTKtFXMkwK8EGp/0OEXAoBbSIiIeAUjAFs038YxRj24IIEI4TGNXfZwCLVDS+51EnNwI9YJ
 fOW5F5l1KiKbHDPsLDj1XytHWaX2jGcNYnFIPVbH1ctj9us7uhttlvJ+F3hBsr1+BfFsCZeu
 +UbpTF67QUxXlbo8FJbDxYQ/WPG5tClBNAXYkaUsrcR3Oe/DYLrdvWbx2P3FKVZZUit+BAxs
 +JhhgPaaMA9GOnagyPSteX5nvEfu0hPmtgMAEQEAAcLBdgQYAQoAIBYhBNn6svnYAFvEk8FO
 3ioX0oqGC+LDBQJfB10EAhsMAAoJECoX0oqGC+LDiBYP/ivrzautlV1odKBYmhWC5uRPazp5
 7Q+Z5q8ak6UkSes9+P8laJRyEcxlGm95BJKiYNq8V9L2HTiLJ1OS+QpDW+xDBVpPoQ6S8Scs
 Tp3YDIze4MPEk22gaWvXAmfr8KACFlDO4GPKTNarN2CL9zoVL8A16O8vIUoPnaH+Qaq3mgy9
 y0HlSPO+Vyy0W1zaxhLg9iG+c0jXNe+NrIZMzgZ6xMlxhUdIRFdsS9somXQbidlu53hSqf1/
 oGv53Xcv0N1O/2rxgXm6eMypl9MzSEVo62VEphxH2rGKzT7/xKB8HgxIwb9P4Zc9N2JI0GOk
 vSliuLlmZplSJoqLl2uXsbz+uo5FLkMGrzHH3gNxjHYDX42rbRx1dkcXNfSMizKXY+N9ICy5
 +6cx/z4Dj6gSucmVYKySRNdlXQ11/mklV/DoJ1bED6nKyqGBbCDuVGpjvaaBpVJutnPtN6M1
 PHSlduJgSI1xQvOc5OiwME2gxiVnXRNYXjdh4DXMjagg1W9GvJnbgSxsKmmEPL2/XaFJRnKK
 NvktDmXISoacIVqyx4nu+X33e212iAltBrZbSGN1Ehx81FP7LmNuV0H/SYAEyogGS5RFlfAn
 zrHPa5TQtrzsrc3UuCmxy7/lPImx1n4bdpD/mTZUWmYHrtmRHpl/VFCi1jrOTpr6f1SAusdA
 ycqrESCJ
In-Reply-To: 
 <CABUevEzt5sF7tcn6=WVW8PTCfrf9qzmHicxN3mt37Th1kwfZHQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/46ef3419-5a67-4d41-95c2-1cb5db8f4d5a%40ongres.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------0iJhFZEQOxKPANKWK0adgnZ0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 10/1/25 10:52, Magnus Hagander wrote:
> On Thu, Jan 9, 2025 at 11:40 PM Álvaro Hernández <aht@ongres.com> wrote:
>
>
>
>     On 9/1/25 18:08, Jeremy Schneider wrote:
>>     On Thu, 9 Jan 2025 17:06:57 +0100
>>     Álvaro Hernández<aht@ongres.com>  <mailto: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.

     Yes, it comes with a whole set of problems. The main one, other 
than upgrades, is that you may end up with inconsistent environments: 
cases where not all images deployed are the same because some 
dependencies have different versions. This may also lead to different 
CVEs present on different servers. This if far from ideal and a problem 
that is starting to be more and more visible.

     While container builders may not be interested in doing all this 
work, I think that it should be done regardless. And over time, it will 
be done more and more. When security and supply-chain attacks are a 
serious concern, precise knowledge of your dependencies is key.

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

     Debian is doing a great job towards reproducibility of the build 
efforts of their packages. However, AFAIK a given package version can be 
updated with a different content --and that's why a service like 
https://snapshot.debian.org exists.


     Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

--------------0iJhFZEQOxKPANKWK0adgnZ0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 10/1/25 10:52, Magnus Hagander
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CABUevEzt5sF7tcn6=WVW8PTCfrf9qzmHicxN3mt37Th1kwfZHQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">On Thu, Jan 9, 2025 at 11:40 PM Álvaro Hernández
          &lt;<a href="mailto:aht@ongres.com" moz-do-not-send="true"
            class="moz-txt-link-freetext">aht@ongres.com</a>&gt; wrote:</div>
        <div class="gmail_quote gmail_quote_container">
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div> <br>
              <br>
              <div>On 9/1/25 18:08, Jeremy Schneider wrote:<br>
              </div>
              <blockquote type="cite">
                <pre>On Thu, 9 Jan 2025 17:06:57 +0100
Álvaro Hernández <a href="mailto:aht@ongres.com" target="_blank"
                moz-do-not-send="true">&lt;aht@ongres.com&gt;</a> wrote:

</pre>
                <blockquote type="cite">
                  <pre>On 9/1/25 10:07, Christoph Berg wrote:
</pre>
                  <blockquote type="cite">
                    <pre>Re: Jeremy Schneider  
</pre>
                    <blockquote type="cite">
                      <pre>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.
 
</pre>
                    </blockquote>
                    <pre>Hi,

could you explain why 250 MB is too much? Disk space these days is
ultra cheap  
</pre>
                  </blockquote>
                  <pre>     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
</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'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>
                  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.<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>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.</div>
        </div>
      </div>
    </blockquote>
    <br>
        Yes, it comes with a whole set of problems. The main one, other
    than upgrades, is that you may end up with inconsistent
    environments: cases where not all images deployed are the same
    because some dependencies have different versions. This may also
    lead to different CVEs present on different servers. This if far
    from ideal and a problem that is starting to be more and more
    visible.<br>
    <br>
        While container builders may not be interested in doing all this
    work, I think that it should be done regardless. And over time, it
    will be done more and more. When security and supply-chain attacks
    are a serious concern, precise knowledge of your dependencies is
    key.<br>
    <br>
    <blockquote type="cite"
cite="mid:CABUevEzt5sF7tcn6=WVW8PTCfrf9qzmHicxN3mt37Th1kwfZHQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote gmail_quote_container">
          <div><br>
          </div>
          <div> </div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div> <br>
                  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 these days, though they're not there
            all the way. But <a
href="https://tests.reproducible-builds.org/debian/reproducible.htmlshows"
              moz-do-not-send="true" class="moz-txt-link-freetext">https://tests.reproducible-builds.org/debian/reproducible.htmlshows</a>
            they're doing really well. <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
        Debian is doing a great job towards reproducibility of the build
    efforts of their packages. However, AFAIK a given package version
    can be updated with a different content --and that's why a service
    like <a class="moz-txt-link-freetext" href="https://snapshot.debian.org">https://snapshot.debian.org</a> exists.<br>
    <br>
    <br>
        Álvaro<br>
    <br>
    <pre class="moz-signature" cols="72">-- 

Alvaro Hernandez


-----------
OnGres</pre>
  </body>
</html>

--------------0iJhFZEQOxKPANKWK0adgnZ0--