Hi David,
sorry for the late reply, and many thanks for you detailed answer.
What I mean with "falls back" is that APT downloads a package linked in
the arch-specific index, if present, and the on from "all" index only if
the package is not listed in the arch-specific one (or if there is no
arch-specific one).
> So you configured apt on the user systems to support riscv64,
> but didn't change anything in the repository?
Not sure what you mean with "configured apt on the user systems to
support riscv64"? I added the key and repo via sources.list.d to a
riscv64 system, as that is all what it needs? Probably you mean
/var/lib/dpkg/arch, which contains riscv64 OOTB, as this system was
generated via debootstrap to generate a base Debian with this
architecture explicitly.
On the repository, binary-all/Packages was added to enable riscv64
system support, and since all Webmin packages declare themselves
(correctly) as "Architecture: all", we though that it would be actually
cleaner and correct to provide an "all" index only, and remove all
arch-specific indexes from the repo. But then we faced this warning,
which is the reason for the confusion, about how it is intended to be done.
Of course we can add binary-riscv64/Packages and the same for all other
new architectures added to Debian in the future, to mute the warning.
But having a large number of duplicate indexes which all contain/link
the the very same "Architecture: all" packages seems somehow
unnecessarily complicated, and even wrong for explicitly arch-agnostic
packages.
> 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.
I see. We were assuming that "all" implies that a repo supports all
architectures, in case at least for the subset of packages listed in the
"all" index. The wiki however does not say anything explicitly about
that, but only that the "all" index is an indicator that "Architecture:
all" packages are not listed in the arch-specific indexes.
I understood now that APT repos are intended to explicitly define every
architecture they support, regardless whether they provide
"Architecture: all" packages only or others as well. I tend to agree
that being explicit is usually better, and in this case means that
someone usually tested the package(s) on the particular architecture
before the repo maintainer does the effort to add it to the repo explicitly.
Thanks for taking your time, so we know now that the intended way is to
add binary-riscv64/Packages to declare riscv64 support explicitly.
Best regards,
Micha
Am 03.12.2023 um 15:27 schrieb David Kalnischkies:
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 fi
