With dpkg native architecture of amd64 and a foreign architecture of i386 enabling the VSCode or .NET repositories results in warnings:

  Notice: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://packages.microsoft.com/debian/13/prod trixie InRelease' doesn't support architecture 'i386'
  Notice: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://packages.microsoft.com/repos/vscode stable InRelease' doesn't support architecture 'i386'

extrepo should write a "Architectures-Remove" directive for all foreign architectures not supported by the target repository to the sources files.
This wasn't an issue prior to the fix of bug #947244 as all supported architectures were listed, but which in turn resulted in overfetching.

reassign 1128277 apt
thanks

No. Apt should stop producing warnings for repositories that do not
carry an architecture that is not enabled on the system.

The new version of extrepo will refuse to enable a repository if none of
the architectures supported by the repository are enabled on the system
(either as the native architecture or as a foreign one). There is
nothing more for extrepo to do. The fact that apt produces a useless
warning that the architecture isn't supported is a bug in apt, not
extrepo.

(you may want to CC maintainers on reassign as they otherwise only
 get the easily missed Processed mail, see dev-ref §5.8.3.2)
[…]

(But it is enabled on the system ???)
be causing problems as the repository is not intended to be used with
i386. It e.g. wont provide M-A:same variants for it possibly causing
a removal cascade or blocking [security] upgrades indefinitely and
other (not so) subtil problems users will attribute to apt and/or
MultiArch as nobody said there will be problems otherwise.
(appart from the general implicit warning about repositories
 in general being able to cause a lot of problems, that everyone
 ignores of course)

A user can avoid this warning (which is an interactive notice only)
by not requesting the architecture as you noticed already, which
amounts to a "I will keep the pieces if that breaks" admission.

A repository can avoid it by "suppporting" the architecture –
which doesn't mean they have to build all their packages for i386.
In fact, they don't need to build any package, not even ship a
binary-i386/Packages file – all apt cares about is that the
Architectures field in the Release file contains 'i386'.

What that means is that the repository actually supports being
used on i386 – as in, they won't break M-A systems or if they
do they at least consider it a bug: They e.g. can and will ship
M-A: same variants of libraries they overtake or an M-A:foreign
provider will actually support being called by the foreign i386
packages installed on the user system.


So, I am considering this a bug in the repositories.


(On a more practical note, the code has no idea why i386 ended up
 being configured for acquire, so it has to do something, for the
 possibility of it being an explicit Architectures-Add thing…)


Best regards

David Kalnischkies