Hi, (I think this isn't a good mailing list for apt vs. third-party repo config… users@ probably could have answered that already, deity@ if you wanted full APT background which I will provide here now… reordered quotes slightly to tell a better story)
On Sat, Dec 02, 2023 at 06:40:33PM +0100, MichaIng wrote: > we recognised that APT falls back to/uses "binary-all/Packages" APT doesn't fall back to it, its default behaviour to use them if available and supported (← that word becomes important later on). Debian repos actually opt out of it for Packages files: https://wiki.debian.org/DebianRepository/Format#No-Support-for-Architecture-all > while checking how to best enable riscv64 support for Webmin's own APT > repository And what did you do to the repository to enable riscv64 support? > but still complains with a warning if no "binary-riscv64/Packages" > is present and declared in the Release file of the APT repository: > ------- > W: Skipping acquire of configured file 'contrib/binary-riscv64/Packages' as > repository 'https://download.webmin.com/download/repository sarge InRelease' > does not seem to provide it (sources.list entry misspelt?) > ------- So you configured apt on the user systems to support riscv64, but didn't change anything in the repository? > Is this expected behaviour, i.e. is every repository expected to provide > dedicated package lists for every architecture, or is there a way to provide > an "all" architectures list only, without causing clients to throw warnings? Yes, i.e. no and yes there is. The previously mentioned wiki says this about the Architectures field: "The field identifies which architectures are supported by this repository." So your repository doesn't support this architecture and doesn't even ship the data, the user has configured apt to get. Something is fishy, better warn about it. So, add riscv64 to Architecture in Release and be done, except that you should read the entire stanza as it will explain how a client will behave with that information. It also explains the specialness of 'all'. https://wiki.debian.org/DebianRepository/Format#Architectures Why? So glad you asked! Nobody tested the repository with this arch. If you e.g. have a Multi-Arch system bad things can happen if a library package is not available for all configured architectures in the same version. Or that arch:all package ships little-endian data, but your system is big-endian (or vice versa), or its actually using linux-only binaries in maintainer scripts, but you are running hurd-i386 … > In case of Webmin, all packages are perl scripts, have "Architecture: all" > declared and naturally support all architectures. So it seems unnecessary to Well, arch:all packages do not "naturally" support all architectures in edge cases and we love edge cases. It is also why an arch:all package is not "naturally" also "Multi-Arch: foreign". > provide clones of a single package list for every architecture explicitly, > and having to do so whenever a new one appears. So yeah, if you want you can ship only an -all/Packages file and add the others if you ever ship some as long as you tell apt (and your users) that you support an Architecture, they will manage. Best regards David Kalnischkies, who happens to have implemented most of this
signature.asc
Description: PGP signature
