>>>>> "Samuel" == Samuel Thibault <sthiba...@debian.org> writes:
Samuel> Why? Having spurious symbols doesn't break the build, and
Samuel> these are internal symbols so that shouldn't harm
Samuel> reverse-dependencies.
Actually, the way I have it configured, extra symbols should break the
build. I want that.
So, summarizing a conversation from debian-devel.
I can mark the symbols (optional) and then they can be present or absent
without breaking the build.
If I do that, the ABI of libkrb5support0 will depend on the version of
glibc that it is built against.
That's problematic, because there is not a strict version dependency
between libk5crypto3 and libkrb5support0.
The dependencies allow an old libk5crypto3 to be installed alongside a
new libkrb5support0.
For that to work, libkrb5support0 needs to not disappear symbols.
I have three options:
1) The option I'm likely to choose is to mark the symbols optional,
break old libk5crypto3 from new libkrb5support0 as a one-time thing, and
create a strict dependency on the binary version from libk5crypto3 to
libkrb5support0.
I *think* this is safe.
The ABI of libkrb5support0 will depend on which glibc we build against,
but nothing outside of the krb5 source package is permitted to care
about that ABI, and a strict binary dependency will make it very likely
(absent local builds) that we get the same build for the ABI provider
(libkrb5support0) and the ABI consumers.
2) I could simply provide the strlcat and strlcpy implementations all
the time, and use them depending on what glibc provides. I know this is
safe: the ABI is consistent, and if we end up using glibc symbols, then
the libc6 symbols file will arrange for the right dependency.
3) I can remove the symbols, make a build-depends of libc6-dev >= 2.38,
and add a breaks of libkrb5support0 on the old libk5crypto3.
This is also safe: it's what I would do if libkrb5support0 wanted to
drop a symbol and I didn't want the strict version dependency.
--Sam
