On Fri, Sep 10, 2021 at 11:08:38AM -0400, Michael Stone wrote: > On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote: > > 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) > > I have no idea what darts is, so I don't have an answer. :) "Darts" was just a play on "bullseye". It is not hard to imagine a repository which has the same suite and component(s) but is not Debian itself. As a pseudo-random [= its in an other topic here] real example you can take Wine (https://dl.winehq.org/wine-builds/debian/). So to what is "deb apt:// bullseye main" referring? Debian or Wine? And to pre-empt the most common response: As an apt dev I can assure you that we won't accept a solution involving "I am on Debian, so it means Debian" as that is impossible to correctly guess programmatically (for example on derivatives using a small overlay repo). > > 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. > > I'm not sure why you think I need that? The goal of my musings is to Because this thread started with the idea to switch the default of d-i and co to another URI. If you target only apt then you still need a solution for d-i and a way to convert whatever d-i had into what apt gets in the end (of the installation). The configuration option which only works with apt tools already exists in the form of the mirror method… > > > 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. > > I have no idea what you're saying here. And I have no idea if you know what you are talking about. auto-apt-proxy already uses an interface apt provides to configure the proxy at runtime. It isn't in the business of modifying sources.list nor has it any interest in that. So you using it as an example for a plugin who could use your proposed scheme to modify the sources at runtime makes no sense. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature