Hi!
On Sun, 2025-12-21 at 11:25:29 +0000, Simon McVittie wrote:
> 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
> > 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?
Sorry, the test cases for the private symbols were probably more
confusing than helpful. The relevant part is:
,--- debian/libbasictags1.symbols ---
libbasictags.so.1 libbasictags1 #MINVER#
| libbasictags1 (>= 1.1)
(private)symbol00_private@Base 0
(optional)symbol11_optional@Base 1.1 1
[…]
`---
Where this would (currently) end up being mapped into the following
generated symbols file in the .deb package:
,--- DEBIAN/symbols ---
libbasictags.so.1 libbasictags1 #MINVER#
| libbasictags1 (>= 1.1)
| #PRIVATE#
symbol00_private@Base 0 -1
symbol11_optional@Base 1.1 1
`---
Where «#PRIVATE#» here is just an invalid dependency that makes the
whole thing fail (even for old dpkg-shlibdeps that might not even have
explicit support for this. For new versions that could be parsed to
give a more meaningful message for example.
For the internal symbols, what I was wondering, was whether it would
be nicer to tag each individual symbol as «(internal)symbol» instead
of pointing it to the #CURVER# alternative dependency, which I think
would make the intention perhaps more clear (as it would be akin to
semantic tagging).
But if the alternative dependency gets automatically generated like
the #PRIVATE# one, then that also means it's going to be less
flexible, and it has the same problem of having to invent an index
(negative for example).
So, I think I'll merge the #CURVER# changes, and then we can either
build more semantic stuff on top of that somehow, or use something
else, or whatever, but at least we'll have now something that can
replace existing cumbersome usages.
Thanks,
Guillem
