Dear Maintainer,

libmariadb-dev cannot be installed for two architectures simultaneously,
which blocks cross-architecture C/C++ development. Two separate problems:

1. The package is not marked "Multi-Arch: same" (no Multi-Arch field at all).

2. Even if it were, it ships two genuinely per-architecture files at shared,
non-triplet paths, so the two arch instances would collide:

* /usr/bin/mariadb_config — a compiled ELF binary. The amd64 and arm64
copies differ at byte 19, i.e. the ELF e_machine field (offset 0x12):
amd64 = x86-64, arm64 = AArch64.

* /usr/include/mariadb/mariadb_version.h — differs only at:
#define MARIADB_MACHINE_TYPE "x86_64" vs "aarch64"
#define MARIADB_PLUGINDIR ".../x86_64-linux-gnu/..." vs aarch64

Status (verified):
- trixie: 1:11.8.6-0+deb13u1 — no Multi-Arch field, both files per-arch
- unstable: 1:11.8.8-1 — same, so not fixed for the next release

Suggested direction (maintainer's call):
* mariadb_config: make it architecture-independent (e.g. a small shell
wrapper that derives the multiarch path), or relocate the per-arch binary
so /usr/bin holds an arch-neutral file.
* mariadb_version.h: either move the header into the triplet include
directory, or drop/neutralise the two multiarch-dependent defines
(MARIADB_MACHINE_TYPE, MARIADB_PLUGINDIR) from the public header.
Then mark libmariadb-dev "Multi-Arch: same".

This is the substantive blocker behind #1140151 (libmariadb-dev-compat) and,
transitively, #1140150 (libpoco-dev). I have working repackaging that does
exactly the above across amd64/arm64 and am happy to share it or test
candidates.

Steps to reproduce:
dpkg --add-architecture arm64; apt-get update
apt-get install -s libmariadb-dev:amd64 libmariadb-dev:arm64

Thanks,
Dick Hollenbeck

Thanks — happy to drive this. Before I push an MR, here's the approach I have
   in mind; since you've hit conflicts on past attempts, I'd rather confirm the
   direction (and hear what previously went wrong) than re-tread it.

   First, the complete scope. I diffed every shared-path (non-triplet) file in
   the dependency closure across amd64 and arm64. The entire co-install blocker
   is just three things:

     * libmariadb-dev-compat: 0 files differ between arches. It only lacks
       Multi-Arch: same.
     * libmariadb-dev: exactly 2 files differ, nothing else (148 shared files
       checked; my_config.h and all other headers are byte-identical):
         - /usr/bin/mariadb_config            (compiled ELF, differs entirely)
         - /usr/include/mariadb/mariadb_version.h  (differs only in
           MARIADB_MACHINE_TYPE and MARIADB_PLUGINDIR)

   If past attempts "ran into conflicts," my guess is an incomplete inventory —
   a missed differing file. I believe the list above is exhaustive for 11.8.8-1.

   Proposed fix:

   1. libmariadb-dev-compat — add Multi-Arch: same. Nothing else differs.
      Open question for you: does its self-Provides + Conflicts/Breaks of
      libmariadbclient-dev-compat / libmariadb-client-lgpl-dev-compat need
      adjusting once it's M-A: same, or is two instances of the same package
      providing the same virtual fine? I'll verify empirically either way.

   2. libmariadb-dev — add Multi-Arch: same and resolve the 2 files:
      a) mariadb_config: replace the compiled binary with an
         architecture-independent POSIX shell script that derives the multiarch
         triplet at runtime (cc -print-multiarch, falling back to
         dpkg-architecture -qDEB_HOST_MULTIARCH). This is the historical
         mysql_config form and makes the file byte-identical across arches.
      b) mariadb_version.h: relocate it to the multiarch include dir
         /usr/include/<triplet>/mariadb/ (auto-searched by the compiler), so
         MARIADB_PLUGINDIR / MARIADB_MACHINE_TYPE may legitimately differ. I'd
         prefer this over neutralizing the defines, which could break consumers
         that read MARIADB_PLUGINDIR — but if you'd rather keep the header in the
         common path and drop/derive those defines, I'm fine with that too.

   Two questions:
     - Does (2a) the shell-script mariadb_config conflict with anything you tried
       before, or with a reason it was made a compiled program?
     - For (2b), do you prefer relocation or neutralizing the defines?

   Once you confirm the direction I'll build it, verify amd64+arm64 actually
   co-install in a clean trixie/sid container, and open the MR at
   salsa.debian.org/mariadb-team/mariadb-server.

   Thanks,
   Dick

Hi,

Thanks for working on this!

I don't have a strong opinion of what's the best way to implement this and
I don't recall why the previous attempts exactly failed. I do however
remember that all the failures previously where immediately visible in the
CI.

For 2a and 2b let's proceed as you see fit. I don't know why mariadb_config
is a binary and I haven't checked git blame. Upstream probably had some
reason but upstream does not really test nor target cross-compiling.

Once we have this fully working in Debian, I hope you can continue by also
submitting your improvements upstream. But let's fix this fully in Debian
and Ubuntu first and see for a few weeks that no regressions surface.

Hi,

Thanks for the go-ahead. Rather than open a salsa MR I'm attaching the
change as a git patch series (generated against the debian/ packaging of
1:11.8.8-1) — happy to push it as an MR instead if you'd prefer, just say
so. You should be able to apply it directly:

     git am 0001-*.patch 0002-*.patch 0003-*.patch

Three commits, all under debian/ (no upstream/quilt patch needed — the
header split is done at build time in debian/rules):

   0001  libmariadb-dev: Multi-Arch: same. Replaces the per-arch compiled
         /usr/bin/mariadb_config with an architecture-independent shell
         script (derives the multiarch triplet at runtime), and moves the
         two arch-varying macros of mariadb_version.h (MARIADB_MACHINE_TYPE,
         MARIADB_PLUGINDIR) into a per-arch triplet stub header so the public
         header is byte-identical across arches. The header is deliberately
         NOT relocated — mysql.h includes it with quotes.   (Closes: #1140296)

   0002  libmariadb-dev-compat: Multi-Arch: same, and drop the two
         self-provided transitional virtuals from Conflicts/Breaks. Marking
         it M-A: same alone is not enough — two arch instances otherwise
         break each other via those virtuals.              (Closes: #1140151)

   0003  changelog entry (1:11.8.8-2 / UNRELEASED — drop or regenerate via
         gbp dch as you like).

What I verified locally (by transforming the real 11.8.6 binaries into this
exact end state): all shared-path files become byte-identical across amd64
and arm64; libmariadb-dev + libmariadb-dev-compat co-install for both arches;
#include <mysql.h> still compiles and links; and mariadb_config output is
unchanged (--cflags/--libs/--plugindir/--version=11.8.6/...). I could not run
a full source build here, so the buildd/CI pass on amd64+arm64 is the final
gate — which is exactly what this targets, since the previous failures you
mentioned were the cross-arch identical-files check.

One thing worth a look before merge: please sanity-check the shell
mariadb_config's flag set against the current compiled binary, in case
something relies on a flag it doesn't yet implement.

Thanks,
Dick Hollenbeck

Hi,

If you have a Salsa account and it is easy for you, I would rather have
this as a MR on Salsa so CI runs and gives you feedback.

Hi Otto,

No sadly I do not have an account and am on my way out of town.

The Salsa guest signup warns it can take days to approve, so I'd rather not
block this on a new account right now. The three patches on the bug are
git-am-able onto debian/latest (it's at 1:11.8.8-1, so they apply cleanly).

Would you be willing to push the branch yourself so the CI runs? I'm glad to
fix up anything it flags. And if you'd still prefer it as my own MR, I can set
up the account and do that once it comes through — just let me know.

Thanks,
Dick