Borderline sh-tpost here.
While “investigating packages” (read: “messing around”) with apt, I seem to have discovered what is, on LMDE7 at least, the longest “Provides” sub-package list. Over 75000 characters.
$ /usr/bin/apt show librust-winapi-dev | grep '^Provides:' | wc -c
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
75650
The warning is irrelevant, but I left it in because it’s a good thing to bear in mind.
It’s also kind of funny because the only way you’re going to be able to parse all of that output is with a tool of some kind.
If I count the commas with a suitable change to that pipeline, there are 1603, so it provides functionality for no less than 1604 other packages.
node-lodash-packages and node-babel7 are distant second and third with ~20000 and ~10000 characters (585 and 202 supported packages) respectively.
Ironically, none of these contain the phrase “kitchen sink”.
Looks like that package was removed from Debian. I wouldn’t be surprised if it was due to not following Debian policy.
Here are the first 100 entries:
$ apt-cache show librust-winapi-dev |grep ^Provides: |sed "s/Provides: "// |sed "s/, /\\n/g" |sed "s/ .*//g" |sort -V |head -100 librust-winapi+accctrl-dev librust-winapi+aclapi-dev librust-winapi+activation-dev librust-winapi+adhoc-dev librust-winapi+appmgmt-dev librust-winapi+audioclient-dev librust-winapi+audiosessiontypes-dev librust-winapi+avrt-dev librust-winapi+basetsd-dev librust-winapi+bcrypt-dev librust-winapi+bits1-5-dev librust-winapi+bits2-0-dev librust-winapi+bits2-5-dev librust-winapi+bits3-0-dev librust-winapi+bits4-0-dev librust-winapi+bits5-0-dev librust-winapi+bits10-1-dev librust-winapi+bitscfg-dev librust-winapi+bitsmsg-dev librust-winapi+bits-dev librust-winapi+bluetoothapis-dev librust-winapi+bluetoothleapis-dev librust-winapi+bthdef-dev librust-winapi+bthioctl-dev librust-winapi+bthledef-dev librust-winapi+bthsdpdef-dev librust-winapi+bugcodes-dev librust-winapi+cderr-dev librust-winapi+cfgmgr32-dev librust-winapi+cfg-dev librust-winapi+cguid-dev librust-winapi+combaseapi-dev librust-winapi+coml2api-dev librust-winapi+commapi-dev librust-winapi+commctrl-dev librust-winapi+commdlg-dev librust-winapi+commoncontrols-dev librust-winapi+consoleapi-dev librust-winapi+corecrt-dev librust-winapi+corsym-dev librust-winapi+d2d1effectauthor-dev librust-winapi+d2d1effects-1-dev librust-winapi+d2d1effects-2-dev librust-winapi+d2d1effects-dev librust-winapi+d2d1svg-dev librust-winapi+d2d1-1-dev librust-winapi+d2d1-2-dev librust-winapi+d2d1-3-dev librust-winapi+d2d1-dev librust-winapi+d2dbasetypes-dev librust-winapi+d3d9caps-dev librust-winapi+d3d9types-dev librust-winapi+d3d9-dev librust-winapi+d3d10effect-dev librust-winapi+d3d10misc-dev librust-winapi+d3d10sdklayers-dev librust-winapi+d3d10shader-dev librust-winapi+d3d10-1shader-dev librust-winapi+d3d10-1-dev librust-winapi+d3d10-dev librust-winapi+d3d11on12-dev librust-winapi+d3d11sdklayers-dev librust-winapi+d3d11shader-dev librust-winapi+d3d11tokenizedprogramformat-dev librust-winapi+d3d11-1-dev librust-winapi+d3d11-2-dev librust-winapi+d3d11-3-dev librust-winapi+d3d11-4-dev librust-winapi+d3d11-dev librust-winapi+d3d12sdklayers-dev librust-winapi+d3d12shader-dev librust-winapi+d3d12-dev librust-winapi+d3dcommon-dev librust-winapi+d3dcompiler-dev librust-winapi+d3dcsx-dev librust-winapi+d3dkmdt-dev librust-winapi+d3dkmthk-dev librust-winapi+d3dukmdt-dev librust-winapi+d3dx10core-dev librust-winapi+d3dx10math-dev librust-winapi+d3dx10mesh-dev librust-winapi+d3d-dev librust-winapi+datetimeapi-dev librust-winapi+davclnt-dev librust-winapi+dbghelp-dev librust-winapi+dbt-dev librust-winapi+dcommon-dev librust-winapi+dcompanimation-dev librust-winapi+dcomptypes-dev librust-winapi+dcomp-dev librust-winapi+dde-dev librust-winapi+ddrawint-dev librust-winapi+ddrawi-dev librust-winapi+ddraw-dev librust-winapi+debugapi-dev librust-winapi+debug-dev librust-winapi+default-dev librust-winapi+devguid-dev librust-winapi+devicetopology-dev librust-winapi+devpkey-devI haven’t reviewed the relevant policies lately, but I suspect those should have been separate packages, not thousands of entries in a single package’s
Provides:field.

