TL;DR: Any encrypted transport protocol (e.g. https) breaks caching. On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote: > This could be useful for both the "I've got a slow uplink and would like > it to not be overwhelmed at the BSP I'm hosting for my Debian friends" > type as well as the "I'm an ISP and I want to provide a mirror to Debian > users so we can reduce our uplink connection a bit" type of situations.
Yes, please. Another situation is: "My home houses around 10 Debian machines, some of which are mobile." I'm actually doing this since around 10 years. My first implementation (predating both auto-apt-proxy and squid-deb-proxy-client) was a custom DHCP option containing a proxy. I've locally used that with success for quite a while in my own environments. It does have a few downsides: * Integrating it with isc-dhcp-client was impossible in a policy-compliant way. * IPv4 only. * As others have pointed out: Breaks with https. Other commenters mentiond squid-deb-proxy-client using _apt_proxy._tcp. via avahi. auto-apt-proxy has a few techniques beyond that. Unfortunately, none of them are enabled by default, so in general it doesn't just work. In any case, I for one would actively opt out of https, because it would make apt unusable for me. My cache has a byte hit rate around 90% - 95%. It seems to deliver around 4TB of .debs and stuff per year here. How would you get that through DSL? Using https would make apt unbearably slow for me. Honouring _apt_proxy._tcp. by default would be cool indeed. apt-cacher-ng automatically publishes this as does squid-deb-proxy. However doing so would completely break if we were to go https by default. Helmut
