Report forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>: Bug#968710; Package debhelper.
(Thu, 20 Aug 2020 14:03:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Simon McVittie <smcv@debian.org>:
New Bug report received and forwarded. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Thu, 20 Aug 2020 14:03:03 GMT) (full text, mbox, link).
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: dh_strip: build-ID-based debug symbols have file conflicts for
duplicate private shared libraries
Date: Thu, 20 Aug 2020 14:58:40 +0100
Package: debhelper
Version: 13.2
Severity: normal
File: /usr/bin/dh_strip
Since compat level 9, debhelper uses build-ID-based detached debug symbols,
which are normally A Good Thing.
However, if two packages contain the same private shared library or
loadable module, and it's 100% reproducible, it can end up with the same
build-ID, causing those packages' detached debug symbols to collide.
One place where this legitimately happens is gnome-documents and
gnome-books, which both contain a copy of the libgd "copylib" (not to
be confused with the libgd2 graphics library, which is unrelated).
libgd is not API-stable, so a system-wide shared copy is undesirable
(and is not required by Debian Policy §4.13, because it is "explicitly
intended to be used in this way"). Normally the copy bundled with a
dependent project would be statically linked into the dependent project,
but gnome-documents and gnome-books are written in JavaScript and use
GObject-Introspection to call into libgd, which means it has to be built
as a shared library. Each app installs its copy into a separate private
library directory, which works fine.
At the moment gnome-documents and gnome-books happen to have identical
libgd source code, although this is by no means guaranteed in future
releases. They are built into binaries that differ, but the build-ID is
identical (presumably the code they contain doesn't differ in any way
that matters for debugging), so -documents-dbgsym and -books-dbgsym
have an undeclared conflict and cannot be co-installed. For now I'm
probably going to work around this by disabling the automatic debug
symbols packages.
Another place where I've seen this happen is that openarena and
openarena-server both ship the "game rules" for OpenArena, qagame*.so,
which is a dlopen()'d loadable module. This is duplication, but
I don't really want to bloat the Packages file by separating out an
openarena-common package to save 800K of installed size, particularly when
that's insignificant next to the 400M+ game data. I worked around this
by building a separate server-side qagame*.so with a different version
number string (0.8.8+dfsg-4/Debian/server vs. 0.8.8+dfsg-4/Debian)
and otherwise identical contents.
Possible solutions:
* perturb the build-ID somehow, similar to my workaround with the
(user-facing) version number string in openarena-server;
* in dh_strip, make it possible to go back to path-based filenames in
/usr/lib/debug;
* in dpkg, extend the reference-counting for identical files in
Multi-Arch: same packages to cover any identical file;
* deploy detached debug symbols in a way that is not dpkg-based
Any ideas?
Thanks,
smcv
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>: Bug#968710; Package debhelper.
(Fri, 05 Feb 2021 11:30:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Fri, 05 Feb 2021 11:30:05 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.