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

Re: Can we make golang-github-mattn-go-sqlite3-dev 'Architecture:all'+'Multi-Arch:foreign' again?



Helmut Grohne <helmut@subdivi.de> 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

Attachment: signature.asc
Description: PGP signature


Reply to: