Bug#1140150: libpoco-dev: not co-installable across architectures in trixie (Multi-Arch: same dropped in 1.13.0-6)

Dick Hollenbeck <[email protected]>
Newsgroups gmane.linux.debian.qa-packages
Message-ID <8695e9f1-78b2-4a3a-9f0c-365e4a5a86fd__36125.4667209991$1781621070$gmane$org@softplc.com>
Package: libpoco-dev
Version: 1.13.0-6+b2
Severity: normal

Dear Maintainer,

In a clean debian:trixie environment with a foreign architecture enabled,
libpoco-dev:amd64 and libpoco-dev:arm64 cannot be installed simultaneously:

# docker run --rm debian:trixie bash
dpkg --add-architecture arm64
apt-get update
apt-get install -s libpoco-dev:amd64 libpoco-dev:arm64
...
libpoco-dev : Conflicts: libpoco-dev:arm64 but 1.13.0-6+b2 is to be
installed
libpoco-dev:arm64 : Conflicts: libpoco-dev but 1.13.0-6+b2 is to be
installed

Root cause: the libpoco-dev binary package in trixie (1.13.0-6+b2) is not
marked "Multi-Arch: same". The field was deliberately removed in 1.13.0-6
("Disclaim libpoco-dev to be MA same", closing my earlier bug #1064971).
Closing #1064971 by dropping Multi-Arch instead of resolving the underlying
file layout means the -dev package is, by design, no longer co-installable
across architectures -- which is a regression for cross-arch development.

The good news: this has effectively already been corrected in unstable.
libpoco-dev 1.14.2-6 (sid) restores "Multi-Arch: same", and I have verified
it is genuinely co-installable: all 855 shared headers under /usr/include
are byte-identical between amd64 and arm64, and every architecture-specific
.so development symlink lives in its triplet path (/usr/lib/<triplet>/), so
there are no shared-path file conflicts.

Request: please restore "Multi-Arch: same" for libpoco-dev in trixie via a
stable update (it is a one-line debian/control change, already present in
1.14.2-6). I'm happy to prepare the debdiff / NMU if that helps, given the
package is currently QA-maintained.

Note on a second, independent blocker (not libpoco-dev's bug, flagged here
for completeness): even with Multi-Arch: same restored, co-installing the
two libpoco-dev arches is still blocked by the dependency on
default-libmysqlclient-dev, whose libmariadb-dev-compat is not co-installable
(libmariadb-dev-compat:amd64 Conflicts libmariadb-dev-compat:arm64). That is
a separate issue in the mariadb packaging and I will report it separately.

Thanks,
Dick Hollenbeck

The patch (Blocker 1) — trivial, and exactly what unstable already did.
Against the 1.13.0-6 source, in debian/control, the libpoco-dev stanza:

Package: libpoco-dev
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends: ${misc:Depends},
libpocofoundation... (= ${binary:Version}),
...


-- System Information:
Debian Release: 13.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.74+deb13+1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpoco-dev depends on:
ii default-libmysqlclient-dev 1.1.1
ii libexpat1-dev 2.7.1-2
ii libpcre2-dev 10.46-1~deb13u1
pn libpocoactiverecord100 <none>
pn libpococrypto100 <none>
pn libpocodata100 <none>
pn libpocodatamysql100 <none>
pn libpocodataodbc100 <none>
pn libpocodatapostgresql100 <none>
pn libpocodatasqlite100 <none>
pn libpocoencodings100 <none>
pn libpocofoundation100 <none>
pn libpocojson100 <none>
pn libpocojwt100 <none>
pn libpocomongodb100 <none>
pn libpoconet100 <none>
pn libpoconetssl100 <none>
pn libpocoprometheus100 <none>
pn libpocoredis100 <none>
pn libpocoutil100 <none>
pn libpocoxml100 <none>
pn libpocozip100 <none>
ii libsqlite3-dev 3.46.1-7+deb13u1
ii libssl-dev 3.5.5-1~deb13u2
ii zlib1g-dev 1:1.3.dfsg+really1.3.1-1+b1

libpoco-dev recommends no packages.

libpoco-dev suggests no packages.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.