Acknowledgement sent
to Wouter Verhelst <[email protected]>:
New Bug report received and forwarded. Copy sent to APT Development Team <[email protected]>.
(Tue, 17 Mar 2020 11:03:03 GMT) (full text, mbox, link).
Subject: Should not download indexes for architectures that are not enabled
Date: Tue, 17 Mar 2020 12:01:24 +0100
Package: apt
Version: 1.8.2
Severity: wishlist
Control: block 947244 by -1
thanks
Hi,
(filing against the version in stable because I can reproduce it there
and my unstable machine is broken at the moment so I can't verify that
it still exists in unstable, but presumably this should not be fixed in
stable...)
The "Architectures:" key in a .sources file (or the "arch=" in a .list
file) defaults to the value of APT::Architectures, which defaults to the
architectures enabled on the system. However, when an explicit list of
architectures is configured for a repository, then this overrides the
default value, regardless of whether the extra architectures are enabled
for the system.
It is possible to modify the default by way of Architectures-Add and
Architectures-Remove, but that requires knowledge of which architectures
are enabled on the system.
It would be useful to have a configuration value that says "this
repository has these architectures available" (let's say we call that
"Architectures-Available:"), so that if, say, APT::Architecture contains
"i386 amd64 riscv64", and "Architectures-Available" contains "i386
amd64", the result would be as though "Architectures-Remove: riscv64"
were specified; but if "Architectures-Available" instead contains "i386
amd64 riscv64 armhf", then the result would be as though no
Architectures-* keys were specified at all, and indexes files for i386,
amd64, and riscv64 (but not armhf) will be downloaded.
The alternatives currently are to either produce a warning message that
a particular architecture is not enabled for a repository, to download
more than is needed, or to create a configuration file that depends on
state outside of the configuration file itself, which for a tool like
extrepo is suboptimal.
Thanks for considering,
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Acknowledgement sent
to David Kalnischkies <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Tue, 17 Mar 2020 15:42:05 GMT) (full text, mbox, link).
Hi,
On Tue, Mar 17, 2020 at 12:01:24PM +0100, Wouter Verhelst wrote:
> default value, regardless of whether the extra architectures are enabled
> for the system.
While perhaps not a very common configuration, it is perfectly legal to
acquire metadata of packages or even packages itself for an architecture
you might not be able to install with dpkg (at the moment). dpkg has no
explicit user support for it, but you can have packages in architectures
installed which do not satisfy the criterion for M-A:foreign, but at
least satisfy dependencies in their architecture (old packages which do
not have an architecture are one super evil example for this).
I e.g. download armel indexes to do queries and stuff as that is a lot
quicker than doing the same on the real armel machine… (yes, I could
chroot, perhaps I even should). The point is it is valid configuration
and some people might make use of that.
> The alternatives currently are to either produce a warning message that
> a particular architecture is not enabled for a repository, to download
Note that this notice (N, not W!) says "doesn't support architecture".
The Release file has an [optional] Architectures field and if it is
available apt will check if the architecture it wants to acquire is
included. If not it will generate the notice. If the Release file
includes the architecture apt will not generate it – even if no Packages
file for that architecture is included in the repository at the moment
(as that would be the same as including an empty file).
So that is a sort-of Available-Architectures field, but at the place it
should be: The repository as it can claim available/support for archs,
a user in sources.list can only guess and use chronically outdated data.
> It would be useful to have a configuration value that says "this
> repository has these architectures available" (let's say we call that
So, what you are asking for is in fact an option to say "it is okay if
(the|a) repository does not support these architectures", am I right?
That shouldn't be too hard to implement, so if you know someone who wants
to give it a try… & we are happy to help with tips and review if needed
(I say that as I have other projects I should finish before embarking on
even more papercut projects, so if we wait for me to do it, we are
talking months at the least. Julian might have better things to do, too).
Regardless of size I highly doubt you could convince the Release team
that this is a feature deserving a stable update… (you may note that
I said "feature" as I don't even see a bug per se here…).
It is possible that I completely misunderstood you though as I basically
ignored your first example (and bugtitle) as it makes no sense to me and
focused on the later examples… Why should someone configure a list of
architectures in sources.list they do not want to be downloaded? That is
like the freaking point of configuring the list in sources.list compared
to just letting apt decide which architectures to download (based on
what dpkg could process by default).
Best regards
David Kalnischkies
Acknowledgement sent
to Wouter Verhelst <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Wed, 18 Mar 2020 10:24:04 GMT) (full text, mbox, link).
Subject: Re: Bug#954138: Should not download indexes for architectures that
are not enabled
Date: Wed, 18 Mar 2020 11:21:57 +0100
On Tue, Mar 17, 2020 at 04:39:58PM +0100, David Kalnischkies wrote:
> It is possible that I completely misunderstood you though as I basically
> ignored your first example (and bugtitle) as it makes no sense to me and
Yes, sorry; I guess my mind got a better handle on what I was trying to
say as I was writing the message, and then forgot to update the earlier
messages.
> focused on the later examples… Why should someone configure a list of
> architectures in sources.list they do not want to be downloaded? That is
> like the freaking point of configuring the list in sources.list compared
> to just letting apt decide which architectures to download (based on
> what dpkg could process by default).
The problem is that apt will produce warning messages if the list of
architecture indexes it tries to download from a repository is not a
strict subset of the list of available architectures at that repository.
If I say "dpkg --add-architecture riscv64", then apt will try to
download riscv64 indexes from *all* my configured repositories,
including those that do not carry riscv64, and produce a warning message
for those that do not carry it. The only way to stop apt from issuing
those warnings (that I can see) is to add explicit configuration for
those repositories to list the architectures that it does support.
I try to do that with extrepo[1], as I think it is bad form to write
configuration files that will produce warning messages. However, the
result is now that I create configuration files which may say things
like "Architectures: i386 amd64 ppc64el" even on systems which do not
have one or more of those architectures enabled as foreign
architectures. While this will not produce warning messages, it does
result in a waste of bandwidth.
I guess what I want is for a way to avoid the warning messages? "Yes,
apt, these architectures are not expected to be there, leave that as is
now, kthxbye".
[1] https://packages.debian.org/extrepo
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22