On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: > The only thing I could see that would be a net gain would be to generalizes > sources.list more. Instead of having a user select a specific protocol and > path, allow the user to just select high-level objects. Make this a new > pseudo-protocol for backward compatibility, and introduce something like > deb apt:// suite component[s] > so the default could be something like > deb apt:// bullseye main > deb apt:// bullseye/updates main > then the actual protocols, servers, and paths could be managed by various > plugins and overridden by configuration directives in apt.conf.d. For
In this scheme the Debian bullseye main repo has the same 'URI' as the Darts bullseye main repo. So, you would need to at least include an additional unique identifier of the likes of Debian and Darts, but who is to assign those URNs? (Currently we are piggybacking on the domain name system for this) Also, but just as an aside, whatever clever system you think of apt could be using, you still need a rather simple system for the likes of tools which come before apt like the installers/bootstrappers as they are not (all) using apt, especially not in the very early stages, and a mapping between them. > If someone wants to use tor by default but fall back to https if it's > unreachable, they can do that. If someone wants to use a local proxy via > http but https if they're not on their local network, they can do that. New > installations could default to https, existing installations can keep doing You can do most of the fallback part with the mirror method backed by a local file. It is of no concern to apt how that file comes to be, so you could create it out of a massive amount of options or simply by hand. I do think if the creation is tool-based it shouldn't be apt as I envision far too many unique snowflakes for a one-size-fits-all approach. (The Tor to https fallback can be done already if we talk onion services to others. You can't fall out of Tor – or redirect into it – through as that would allow bad actors to discover who you are/that you have an operational tor client installed. proxy configuration you can already change programmatically on the fly – a job auto-apt-proxy implements –, changing the mirror file with a hook from your network manager would be equally easy.) > their thing, and a plugin like auto-apt-proxy can override defaults to do > something more complicated, using more policy-friendly .d configurations > rather than figuring out a way to rewrite some other package's configuration > file. JFTR: auto-apt-proxy has nothing to do with sources. It is true that apt-cacher-ng (and perhaps others) have a mode of operation in which you prefix the URI of your (in that case caching) proxy to the URI of the actual repo, but that isn't how a proxy usually operates and/or is configured. Best regards David Kalnischkies
signature.asc
Description: PGP signature
