Your message dated Mon, 20 Jan 2025 10:49:17 +0100
with message-id <[email protected]>
and subject line Re: Can we make golang-github-mattn-go-sqlite3-dev
'Architecture:all'+'Multi-Arch:foreign' again?
has caused the Debian Bug report #1093567,
regarding Can we make golang-github-mattn-go-sqlite3-dev
'Architecture:all'+'Multi-Arch:foreign' again?
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1093567: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093567
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: golang-github-mattn-go-sqlite3-dev
Version: 1.14.24~ds1-1
Hi
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:
jas@kaka:~/p$ diffoscope
golang-github-mattn-go-sqlite3-dev_1.14.24~ds1-1_amd64.deb
golang-github-mattn-go-sqlite3-dev_1.14.24~ds1-1_armel.deb
--- golang-github-mattn-go-sqlite3-dev_1.14.24~ds1-1_amd64.deb
+++ golang-github-mattn-go-sqlite3-dev_1.14.24~ds1-1_armel.deb
├── control.tar.xz
│ ├── control.tar
│ │ ├── ./control
│ │ │ @@ -1,11 +1,11 @@
│ │ │ Package: golang-github-mattn-go-sqlite3-dev
│ │ │ Source: golang-github-mattn-go-sqlite3
│ │ │ Version: 1.14.24~ds1-1
│ │ │ -Architecture: amd64
│ │ │ +Architecture: armel
│ │ │ Maintainer: Debian Go Packaging Team <[email protected]>
│ │ │ Installed-Size: 487
│ │ │ Depends: libsqlite3-dev
│ │ │ Breaks: textql (<< 2.0.3-5), zabbix-web-service (<< 1:7.0.5)
│ │ │ Section: golang
│ │ │ Priority: optional
│ │ │ Multi-Arch: same
jas@kaka:~/p$
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:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035646
And today it seems 'libsqlite3-dev' builds on all archs:
https://buildd.debian.org/status/package.php?p=sqlite3
So can we make 'golang-github-mattn-go-sqlite3-dev' an arch:all package
again?
This is one of few golang-* packages which are arch:any, and it seems to
be causing unnecessary build churn and build dependency issues.
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?
Cc'ing Helmut since he wrote the bug report that led to this change, and
I suspect you understand these questions better than most.
/Simon
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Helmut Grohne <[email protected]> writes:
>> 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].
...
> [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.
Thanks! All that helps my understanding, and I share the notion that
this is a workaround for a deeper problem. I also reached the same
conclusion.
Closing...
/Simon
signature.asc
Description: PGP signature
--- End Message ---
