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

Bug#954138: Should not download indexes for architectures that are not enabled



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


Reply to: