Hi Simon, On Mon, Jan 20, 2025 at 12:28:42AM +0100, Simon Josefsson wrote: > I noticed that some packages like 'sigstore-go' doesn't build due to B-D > problems on some archs: > > https://buildd.debian.org/status/package.php?p=sigstore-go > > One reason for that is golang-github-mattn-go-sqlite3-dev. > > So I looked at that package and noticed that it only contain identical > source code files built for all architectures. All archs I checked > (amd64, arm64, armel, armhf) are identical, except for a tiny diff:
Your observation is correct. > Looking at history of this package, I found this change was introduced > via > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984701 > > and if I understand the argument correctly, it is that at that time > (2021) 'libsqlite3-dev' was not available on several archs. However in > 2023 at least one additional arch was fixed: The argument is subtly different. It is not about whether libsqlit3-dev would build or not. It is about correct transference of the architecture constraint down to dependencies. Say you depend on golang-github-mattn-go-sqlite3-dev:arm64 and it would be A:all M-A:foreign, but you actually are on an amd64 system. Then your dependency would be considered satisfied, but the dependency on libsqlite3-dev would become libsqlite3-dev:amd64. Linking the amd64 libsqlite3.so into an arm64 does not work. In this case, golang-github-mattn-go-sqlite3-dev would become rc-buggy as it was missing a required dependency on libsqlite3-dev:arm64. Unfortunately, you cannot simply add "libsqlite3-dev:arm64 [arm64]" as a dependency to an A:all package. In order to have architecture-dependent dependencies you have to change to A:any. Then you can drop M-A:foreign and then your architecture constraint becomes correct (which is the status quo). > So can we make 'golang-github-mattn-go-sqlite3-dev' an arch:all package > again? No[1]. > This is one of few golang-* packages which are arch:any, and it seems to > be causing unnecessary build churn and build dependency issues. There are more to become A:Any. Basically, whenever a go library transitively depends on a C library, being A:all is wrong. The Rust universe has mostly captured this and simply turned all Rust crates A:any. > My biggest concern in doing this change: bookworm shipped with a > arch:all package. How are upgrades handled from bookworm if trixie will > ship a arch:any package? Does it just work, or does it fail horribly > somehow? Changing the architecture of a package between all and any is a common operation and just works. > Cc'ing Helmut since he wrote the bug report that led to this change, and > I suspect you understand these questions better than most. Thank you for asking. Helmut [1] In principle, I'd really like us to, but that is a very deep can of worms. It would take changing the semantics of apt and dpkg. It would require us to abandon the concept of a "native" architecture and instead attach an architecture to each arch:all package at installation time. Doing this would solve a ton of problems (including this one), but it would also cause a ton of others.
