Bug#615940: dpkg-gensymbols: support a #CURVER# substitution to generate strict dependencies

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