#1111197 Multiarch installation fails due to conflicting files

Package:
libpsl-dev
Source:
libpsl-dev
Description:
Library for Public Suffix List (development headers)
Submitter:
NN 708
Date:
2026-08-13 14:51:02 UTC
Severity:
normal
#1111197#5
Date:
2025-08-15 12:47:57 UTC
From:
To:
When attempting to install both AMD64 and ARM64 architectures of 
libpsl-dev simultaneously, the installation fails due to conflicting
'/usr/share/man/man3/libpsl.3.gz' files.

To reproduce on an AMD64 host:
# dpkg --add-architecture arm64
# apt update
# apt install -y libpsl-dev libpsl-dev:arm64
...
Selecting previously unselected package libpsl-dev:amd64.
Preparing to unpack .../08-libpsl-dev_0.21.2-1.1+b1_amd64.deb ...
Unpacking libpsl-dev:amd64 (0.21.2-1.1+b1) ...
...
Selecting previously unselected package libpsl-dev:arm64.
Preparing to unpack .../10-libpsl-dev_0.21.2-1.1+b1_arm64.deb ...
Unpacking libpsl-dev:arm64 (0.21.2-1.1+b1) ...
dpkg: error processing archive /tmp/apt-dpkg-install-Gma12Z/10-libpsl-dev_0.21.2-1.1+b1_arm64.deb (--unpack):
 trying to overwrite shared '/usr/share/man/man3/libpsl.3.gz', which is different from other instances of package libpsl-dev:arm64
Errors were encountered while processing:
 /tmp/apt-dpkg-install-Gma12Z/10-libpsl-dev_0.21.2-1.1+b1_arm64.deb
Error: Sub-process /usr/bin/dpkg returned an error code (1)

This is reproducible on both Debian 13 (trixie) and Debian sid.
#1111197#10
Date:
2026-03-14 13:34:45 UTC
From:
To:
Hello all,

just dropping some notes here after having looked into this a bit.

That manpage contains a date string derived during build from the latest
Debian changelog entry. But when the package is binNMU'd, this binNMU's
changelog date is used instead, and that date might then differ
depending on when the architecture-specific binNMU actually occurred,
which might or all too easily might not be on the same date, making the
resulting packages potentially fail to be co-installed as seen above.

For reference, as such the 0.21.2-1.1 packages were still
co-installable, whereas the +b1 and the +b2 were not anymore.

I am unsure how to best tackle this issue. It would be possible to
override SOURCE_DATE_EPOCH during build, ignoring any binNMU datestamps,
but that seems error-prone and invasive. On the other hand, sbuild
already supports --binNMU-timestamp, but I don't know whether it can be
relied upon to be set during each binNMU.

So, no solution as of yet, but I will keep checking.

Cheers,
Flo
#1111197#15
Date:
2026-05-18 06:12:56 UTC
From:
To:
JFTR, some more background info on the general topic in the thread
starting at <https://lists.debian.org/debian-devel/2026/05/msg00183.html>.

Cheers,
Flo
#1111197#20
Date:
2026-08-02 06:01:07 UTC
From:
To:
This should be fixed with the recent upload of 0.23.1-1, thanks to Tim
Rühsen and Chris Lamb. I'll run some tests, and if they all succeed I
will close this bug with that version.

Cheers,
Flo
#1111197#25
Date:
2026-08-04 15:02:37 UTC
From:
To:
Cheers,
Flo
#1111197#30
Date:
2026-08-13 14:49:57 UTC
From:
To:
Version: 0.23.2-1

With the additional changes in upstream 0.23.2 the manpage contents
remains stable even when binNMU'ing the package, thus now closing this
bug here with the corresponding Debian revision. Thanks to "Bernhard M.
Wiedemann" <bwiedemann@suse.de> and Tim Rühsen <tim.ruehsen@gmx.de>.

Cheers,
Flo