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
Attachment:
signature.asc
Description: PGP signature