Bug#1021948: libsdl2-net-dev: dangling symlink libSDL2_net-2.0.so

[Simon McVittie]

Control: severity -1 normal

On Mon, 17 Oct 2022 at 21:54:35 +0200, Sven Joachim wrote:
> Package: libsdl2-net-dev
> Version: 2.2.0+dfsg-1
[note lack of RC severity]
> 
> Your package contains a dangling symlink:
> 
> ,----
> | $ file /usr/lib/x86_64-linux-gnu/libSDL2_net-2.0.so
> | /usr/lib/x86_64-linux-gnu/libSDL2_net-2.0.so: broken symbolic link to libSDL2_net-2.0.so.0.0.1
> `----
> 
> This symlink is created via dh_link in debian/rules with a comment that
> it exists to fix a dev-pkg-without-shlib-symlink lintian warning.  It
> seems that this warning does no longer trigger, though.

On Wed, 03 May 2023 at 19:19:39 +0200, Andreas Beckmann wrote:
> usertags 1021948 piuparts
> severity 1021948 serious

I don't think this is a RC bug unless other packages are relying on the
dangling symlink to point to something useful, which it appears they are
not (see <https://codesearch.debian.net/search?q=SDL2_net-2.0&literal=1>).
The canonical name of this library for linking purposes is SDL2_net,
as in `cc -otest test.o -lSDL2_net`, which results in linking to either
libSDL2_net.so or libSDL2_net.a (and there is no libSDL2_net-2.0.a).

The libSDL2_net-2.0.so symlink would only be required if someone is
linking dependent programs or libraries with "-lSDL2_net-2.0", and it
seems nothing in Debian does that.

Unless there is a reason why this needs to be considered release-critical
that isn't obvious to me?

When elevating a bug report to release-critical, please mention why you
believe it's a release-critical problem in a mail to the bug, otherwise
the maintainer has no context for it (and might not even be aware that
its severity has been raised).

I agree that the dangling symlink is a bug, and libSDL2_net-2.0.so should
either not exist, or point to a file that exists (the easiest would be
libSDL2_net-2.0.so.0, matching what happens in the rest of the libsdl2
family).

The libsdl3 prerelease in experimental has removed this weird
historical versioning thing, and just ships libSDL3.so, libSDL3.so.0
and libSDL3.so.0.0.0, as is conventional; the extra names with -2.0 in them
are a historical quirk of the upstream build system for the libsdl2 family,
which used `libtool -release`, apparently due to a misunderstanding.

    smcv