Re: Can we make golang-github-mattn-go-sqlite3-dev 'Architecture:all'+'Multi-Arch:foreign' again?
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.
Reply to: