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

Re: [APT repo] Provide a binary-all/Packages only, no primary arch list

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 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
Reply to: