Package: dh-dlopenlibdeps
Version: 0.20
Severity: wishlist
The upstream developer of a package might not have the same idea about
the importance of a dependency that Debian does, because they have to
think about every possible use-case, whereas Debian maintainers only
need to consider Debian's (and derivatives') use-cases. For example in
src:libsdl3, libGLX and libEGL are only
SDL_ELF_NOTE_DLOPEN_PRIORITY_SUGGESTED because in principle a user of
SDL might only be using Vulkan or unaccelerated graphics, but in
practice "most" SDL games want some sort of GL available, so I've bumped
up those dependencies to Recommends for Debian's purposes.
At the moment, a maintainer can raise the importance of dependencies by
hard-coding extra dependencies in d/control (as I'm currently doing in
src:libsdl3), but that technique can't lower the importance of a
dependency, and has a risk of emitting nonsense dependencies if
libraries bump their SONAME or are renamed during a transition (for
example libfoo0 -> libfoo0t64).
To lower the importance of a dependency, or to change the importance of
a dependency without needing to hard-code its binary package name, it
would be necessary to patch the upstream source so that it generates a
different dlopen note, which can result in ongoing merge conflicts if
the relevant code gets reformatted.
This might be nicer if dh-dlopenlibdeps could read a file or command-line
options that map SONAMEs to priorities, perhaps like this:
# Most games want OpenGL even though upstream only Suggests this
libEGL.so.* Recommends
libGLX.so.* Recommends
libOpenGL.so.* Recommends
# Upstream recommends the libfoo family but most games don't need it
libfoo* Suggests
It might also be good to have a way to behave as though an extra dlopen
note had been present, without actually patching the upstream source.
smcv
