On Wed, Sep 13, 2023 at 06:42:11PM -0300, Andreas Hasenack wrote:
> > krb5 was a special case because its "internal" symbols used a prefixed name,
> > so the glibc implementation was not a drop-in ABI-compatible replacement.
> > For the common case, libraries are providing symbols with the literal names
> > "strlcat" and "strlcpy"; if the build system detects these names in the
> > system libc it will omit them at build time. Unless there's some extremely
> > unusual linkage, reverse-dependencies that need this symbol will then just
> > pick it up from libc6 instead.
> > So if these library packages pick up a versioned Depends: on libc6 (>= 2.38)
> > automatically, no further source changes should be needed. And if they
> > don't have a versioned Depends: for some reason, it should be sufficient to
> > manually add one.
> We still need to address the removal of the strl* symbols from each
> library package that previously had it in its d/*.symbols packages,
> right? Should we settle on marking them as optional?
Yes, you would need to update the .symbols files. I would recommend simply
dropping them rather than marking them optional, since if they come back
again that indicates a DIFFERENT problem.
If you need something upstreamable to Debian, then you'll need to mark them
optional since Debian unstable is still on glibc 2.37.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
