Bugs like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901771
indicate that d-devlibdeps is based on the assumption that the -dev
package for libfoo.so.2 will be libfoo2-dev. However, that naming
convention is discredited, and was specifically removed from Policy
4.0.0: see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568374>
and <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493951>. The
recommendation is now to use libNAME[-]APIVERSION-dev if the upstream
developer plans to support multiple parallel-installable APIs (not
ABIs!), like GTK+ and libostree, or plain libNAME-dev if the upstream
developer only plans to support one API version at a time, like libfribidi
and libflatpak.

Since d-devlibdeps is based on an assumption that does not hold, it
will need to grow an increasingly long list of exceptions to the naming
convention that it assumes. I would recommend that packages should not
use d-devlibdeps, and d-shlibs should deprecate it.

    smcv

...

A few years later, d-devlibdeps has a list of 182 overrides.

I was curious how big a problem this was, so I picked 20 random lib*-dev
libraries from those visible to my laptop (which has unstable, testing,
stable and oldstable apt sources, so some of these could be obsolete
packages), excluding Rust because those are not shared libraries:

$ grep-aptavail -e '^lib.*-dev$' -FPackage -sPackage -n | grep -v 'librust-' | sort -u | shuf | head -n20
libboost-timer1.74-dev
libwxsqlite3-3.2-dev
libkf5gravatar-dev
liblitehtml-dev
libs3d-dev
libgnatprj10-dev
libitpp-dev
libxcb-dri2-0-dev
libcanberra-gtk3-dev
libweston-5-dev
libxmlrpc-core-c3-dev
libid3-3.8.3-dev
libxmlada-schema12-dev
libpolylib64-dev
libukui-powerclient-dev
libunwind-dev
libfriso-dev
libghc-heterocephalus-dev
libkmod-dev
libvc-dev

Of these 20 libraries, only libgnatprj10-dev, libxcb-dri2-0-dev and
*maybe* libxmlada-schema12-dev match d-devlibdeps' assumption (I couldn't
find a libxmlada-schema12 shared library so I'll give it the benefit of
the doubt). Needing an override for around 85% of libraries doesn't seem
like a favourable hit rate.

https://packages.debian.org/testing/libdevel/ says there are 5979
packages in the libdevel section, so if my sample is representative,
I would expect d-devlibdeps to need a list of about 5000 overrides to
produce correct results for all libraries. Even if we assume half of those
are rarely-used or false positives (for example static-only libraries),
that's still 1 order of magnitude more than it actually has.

As I had expected, most of the other -dev libraries in my sample seem
to be following the convention in Policy §8.4, so that linking with
something like -lvc or -lpolylib64 (resulting in a DT_NEEDED dependency
on libvc.so.0 or libpolylib64.so.8, represented in dpkg as Depends:
libvc0 or libpolylib64-8) is done via a -dev package named libvc-dev or
libpolylib64-dev, as opposed to the libvc0-dev and libpolylib64-8-dev
that d-devlibdeps assumes is normal.

    smcv