[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1021885: marked as done (apt: please add a command for "give configured $DEFAULTVENDOR mirror")

Your message dated Tue, 25 Oct 2022 08:35:17 +0200
with message-id <20221025063517.ply6cyx53bptpadh@crossbow>
and subject line Re: Bug#1021885: apt: please add a command for "give configured $DEFAULTVENDOR mirror"
has caused the Debian Bug report #1021885,
regarding apt: please add a command for "give configured $DEFAULTVENDOR mirror"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1021885: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021885
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: apt
Version: 2.5.3+b1
Severity: wishlist

Hi!
I see that random programs parse apt's configuration to obtain the default
mirror for use with chroots/containers/etc.  And they all do it in their own
hacky and incomplete ways.  Thus eg. piuparts fails to understand 822-style
sources, and so on.

I started looking how to implement that, and went:
 * `apt-cache policy` has that needed information
 * /etc/dpkg/origins/default gives $Vendor
 * ... so the highest-priority entry with "release o=$Vendor" should do
 * but is that o= or l= ?
You see where it is going...

As you acolytes of the Cow know the right way to do so, while me and all
those piudockernetesemu authors don't -- could you please implement
`apt-cache defaultmirror` or such?


Meow!

--- End Message ---
--- Begin Message --- 
On Sun, Oct 16, 2022 at 05:25:44PM +0200, Adam Borowski wrote:
> I see that random programs parse apt's configuration to obtain the default
> mirror for use with chroots/containers/etc.  And they all do it in their own
> hacky and incomplete ways.  Thus eg. piuparts fails to understand 822-style
> sources, and so on.

tl;dr: Please define what a $DEFAULT $VENDOR $MIRROR is.


> I started looking how to implement that, and went:
>  * `apt-cache policy` has that needed information

Depends on having 'apt update' (or equivalent) run since someone last
cleared /var/lib/apt/lists. I am told that e.g. many Docker images do
this all the time.


>  * /etc/dpkg/origins/default gives $Vendor

(I somehow doubt every derivative sets this. What about derivatives who
 really aren't, like those just providing an "overlay" over testing/sid
 by just shipping with an additional (=their) repo in sources)


>  * ... so the highest-priority entry with "release o=$Vendor" should do
>  * but is that o= or l= ?

Origin (o=) and Label (l=) are values the vendor can choose freely and
do not by definition provide a 1:1 mapping as they pre-date most of
deb-origins usage and I would hope each derivative (well, each repo)
picks somewhat fitting values here, long before even dreaming of using
deb-origins (if applicable at all – many repos target a vendor, but
aren't itself the vendor they target, so at least for this repo origin
is supposed to be != vendor).

Lets see some real world values:
  v=11-updates,o=Debian,a=stable-updates,n=bullseye-updates,l=Debian
  v=11,o=Debian,a=stable-security,n=bullseye-security,l=Debian-Security
  v=11.5,o=Debian,a=stable,n=bullseye,l=Debian
  v=11.5,o=Debian,a=stable-debug,n=bullseye-debug,l=Debian debug
  o=Debian Backports,a=buster-backports,n=buster-backports,l=Debian Backports
  o=Debian Ports,a=unstable,n=sid,l=ftp.ports.debian.org
 
Interestingly, all those COULD have the same mirror by using
deb.debian.org, but e.g. security is probably picked from elsewhere.
Oh, and is security & updates part of your $DEFAULT? For many tools it
isn't, but e.g. mmdebstrap does have it.

Note how Debian and Debian ports might refer to the same release (sid)
with the same packages (= same deb-origin) – just for other
architectures – but completely different o= and l= settings, so whatever
logic you deploy for Debian will need exceptions to treat Debian Ports
correctly.

So far we have assumed that $MIRROR is something online – but that isn't
required to be true. A Debian user could e.g. have pulled and burned the
entire stable archive on DVDs and have them in their sources and perhaps
only picks -updates from a more remote storage.

Apropos remote: If that would run on my system, the mirror you would get
is "tor+mirror+file:/etc/apt/mirror.lst". What is a non-apt tool
supposed to do with that information? Slightly more common are perhaps
proxies like apt-cacher-ng (or the hinted at Tor) which might or might
not be reachable at all from inside your tools network (namespace)…


> You see where it is going...

Yes, into a giant hairball of problems making sense of what was supposed
to be apt-specific configuration so that others might be able to use it
who have no (direct) relation to apt.

 
> As you acolytes of the Cow know the right way to do so, while me and all
> those piudockernetesemu authors don't -- could you please implement
> `apt-cache defaultmirror` or such?

What if I wanted to use the piudockernetesemu on Debian to do $STUFF
for vendor Ubuntu, like build a package for it. Wouldn't that mean we
need to know what $DEFAULTMIRROR is for Ubuntu on a Debian system and
that without having downloaded data previously. Oh, and wouldn't it be
nice if the tool would also know which archive key will be needed…
(and if I can get the default mirrors for sid on stable, …, …, …, …)

So, how about going the other way around: Create a package which keeps
a database on which $MIRROR to choose for which $VENDOR by default for
a $RELEASE and a way for a user to change this, so that all tools can be
changed to ask that database first. You may want to make that extensible
enough that it can store a bunch of information. Depending on how that
works, we could have d-i set the mirror via this and apt (and others) to
pull defaults from there.

Not sure if it is realistic to assume that apt could switch, but others
probably could more easily, and there is at least one part of apt which
could make use of this: /usr/share/doc/apt/examples/sources.list

(Yes, that file is vendor-specific, we just have a very small set of
 vendors and we mainly implemented it to bring in existing forks just
 patching those files, we are not actually aspiring to be an index of
 all possible vendors as that isn't flexible enough)


So, with all this reasoning, I am closing this bugreport on apt as
I don't think we are the right place to tackle this nor do we have the
resources to drive it and if we keep it open here it will just stay open
without any action for all of eternity as most other of our (not-)bugs
as nobody really looks at them.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: