* Michael Stone <mstone@debian.org> [2021-09-09 08:32]:
None of that speaks to whether an organization that deploys such a thing has the ability to manage other configuration settings, even if for some settings there's a desire for additional flexibility.I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management?The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully.
I don't understand your point. You asked for a target audience for auto-apt-proxy. I gave you a legitimate (and real-world) example for such a deployment. Why should it matter whether or not an organization has other configuration facilities? As another example, nobody says: "the target audience for DHCP is an organization who has an infrastructure with full control over a network, including IP address management, but apparently can't configure IP addresses at install time or via some sort of runtime configuration management" and concludes that DHCP is useless. auto-apt-proxy (or DHCP for that matter) *is* the runtime configuration management, and a quite efficient one at that. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
Attachment:
signature.asc
Description: PGP signature