On Thu, 28 Jun 2018 at 12:11:29 +0100, Simon McVittie wrote: > 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 ... > 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.
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
