On Sun, 21 Dec 2025 at 11:31:48 +0100, Guillem Jover wrote:
On Sat, 2025-12-20 at 14:11:51 +0100, Chris Hofstaedtler wrote:
On Tue, Mar 01, 2011 at 08:47:58AM +0100, Raphael Hertzog wrote:
> What is missing however is a way to have that alternate dependency
> embed the strict versioning scheme. For this we need to support a new
> #CURVER# substitution that is replaced with the current version so that
> we can keep the associated dependency in sync with the latest version of
> the package.
I'd also like this. For src:multipath-tools I've for now copied the
solution from src:dbus:
https://sources.debian.org/src/dbus/1.16.2-2/debian/libdbus-1-3.symbols.in#L2
https://sources.debian.org/src/dbus/1.16.2-2/debian/rules#L265
I briefly looked how difficult this could be, and ended up with the
following set of changes (not tested beyond the test suite):
https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=next/dpkg-gensymbols-CURVER
This certainly looks like a nicer way to provide what dbus wants,
without having to use our own .in substitution.
But then wondered whether it might be better to instead add a tag to
mark each symbol with say "(internal)" or something along those lines,
to make it more clear when looking at a particular symbol. Although if
there is going to be a use for #CURVER# besides internal or ABI
unstable symbols, then perhaps that makes sense to be implemented as it
is anyway (or both could be provided).
There are levels of instability. For dbus' use-case, the affected
symbols are private to the dbus source package, but binary packages
outside libdbus-1-3 are allowed to use them, and that's why we have them
in the binary interface at all: they're used by dbus-daemon(1), and by
some of the as-installed tests that are run by autopkgtest. So we can't
have a policy like "if you depend on these symbols then you'll FTBFS".
(In dbus, truly private symbols are filtered out from the ABI by using
-fvisibility=hidden: the symbols in the LIBDBUS_PRIVATE_* verdef are
those that are outside the public API, but are required for in-tree use
by either the tools or the tests.)
I suppose we could combine your #PRIVATE# pseudo-dependency (which makes
any dependent packages intentionally FTBFS, if I understand correctly)
with a shlibs.local that overrules the .symbols and generates a
lockstep-versioned dependency on libdbus-1-3 instead? Is that what you
had in mind?
smcv
