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

Chris Hofstaedtler <[email protected]> Sun, 21 Dec 2025 12:57:21 +0100
Newsgroups gmane.linux.debian.devel.dpkg.bugs
Message-ID <[email protected]>
* Simon McVittie <[email protected]> [251221 12:25]:
>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.

For src:multipath-tools this would seem very nice indeed.

>>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).

>[..]
>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?

That would also sound good for src:multipath-tools.

Many thanks for working on this!

Best,
Chris