libctf soname already in use

libctf soname already in use

[Matthias Klose]

https://bugs.debian.org/1001276 points out that the libctf soname is already in
use on at least FreeBSD and KFreeBSD, the latter being part of Debian as a port
architecture.  I'm unsure how to handle that given that this doesn't seem to be
a problem outside of Debian.  Is the ctfutils package built and used on other
distros as well? Any thoughts?

Matthias

Re: libctf soname already in use

[Nick Alcock]

On 6 Jan 2022, Matthias Klose stated:

> https://bugs.debian.org/1001276 points out that the libctf soname is already in
> use on at least FreeBSD and KFreeBSD, the latter being part of Debian as a port
> architecture.  I'm unsure how to handle that given that this doesn't seem to be
> a problem outside of Debian.  Is the ctfutils package built and used on other
> distros as well? Any thoughts?

AIUI, the libctf.so.1 in ctfutils is basically an internal
implementation detail of ctfutils, with no other package linking against
it. (I don't know how to do the equivalent of apt-rdepends for an arch I
don't have installed, or I'd check). As such, the right thing to do is
probably to put the ctfutils libctf.so.1 in a libdir subdirectory,
perhaps ${libdir}/ctfutils, and point at it with an rpath: this is
basically the only allowed use of rpaths in Debian Policy, so it should
be OK, I think.

This conflict does not arise on FreeBSD itself because the CDDL
ctfutils is part of core, while binutils is a port: so binutils libctf
ends up in /usr/local/lib, and FreeBSD's pervasive use of rpaths keeps
the ctfutils and binutils libctfs from gett confused with each other.

Of course, the reason why they have the same soname is in large part
that they have common ancestry (though binutils libctf has changed much
more and its soname has been reset to zero and climbed back from there
in the process: there is no attempt to be API or ABI-compatible with the
original Solaris libctf, though they are still similar). Even if we
fixed the soname there'd still be the problem that libctf.so would have
the same name in both devel packages. This problem is intractable in
general, with every distro coming up with their own kludge (RH's
software collections, the alternatives system, etc). Even pkgconfig
would only help a little.

In this case it is nice and easy to solve: binutils libctf is meant for
general external use by whatever other programs want to link against it:
its API and ABI are stable, and if people have suggestions for e.g. API
improvements I am very happy to hear them and very likely to accept
them. AIUI, this is not true of ctfutils libctf. (Even when it was in
Solaris it had only a couple of users and use by any other programs was
fairly strongly discouraged: while not *quite* an internal
implementation detail of the kernel and DTrace there was no attempt to
make it useful for other purposes. I hope for DTrace to be just one of
many users of binutils libctf!)

Fundamentally this is a distro integration problem -- if you want to
move binutils libctf.so.1 into a subdir in Debian, that's fine too, but
I think in that case we should arrange for upstream binutils to install
a libctf.pc pkgconfig file so that other users of binutils libctf don't
need to grow special-purpose hacks for Debian but can just use
pkg-config to pull it in.

-- 
NULL && (void)