On Sun, Apr 20, 2025 at 06:05:13PM +0100, Josh Triplett wrote: > On Sun, Apr 20, 2025 at 12:48:08PM +0200, Simon Josefsson wrote: > > Josh Triplett <j...@joshtriplett.org> writes: > > > > > And the extra symlinks in `/etc/alternatives` don't take much size; I > > > agree you don't need update-alternatives, but then, you also don't > > > strictly need the entire dpkg and apt packages, if you're already > > > omitting their files under /var/lib. > > > > Right -- has anyone considered if Debian should have official containers > > without apt and dpkg? I think that for many use-cases for containers, > > apt and dpkg will not be used and just take up space. Guix packs > > (containers) doesn't get Guix installed unless you specify that as a > > package you want to have installed (which is usually not necessary), so > > something like this should be possible. > > The tricky part of that would be that you then couldn't use that > container image as a base and install any further packages. Offering a > "stock" container image without dpkg and apt would mean that the > container image has to *already* have everything installed that people > using the container need. (By contrast, if someone is installing their > own container they could then finalize it by removing dpkg and apt and > other things not needed at runtime.) > > I think it's a good idea to support this case, but I would ideally want > to support it in tools that people use to build containers. For > instance, suppose we had an mmdebstrap option to purge dpkg and apt and > associated paraphernalia, after installing everything needed. >...
This would be for the use case where a user does not want to be able to install security updates, but does need binary compatibility with Debian. That's a rare use case. When binary compatibility is not required, source-based distributions will always provide smaller images with slightly better performance. cu Adrian
