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).
> > 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.