As a former distro maintainer, I can name 3 possible explanations for what the author saw: 1. The author's method of finding dependencies by looking at `ldd` o

As a former distro maintainer, I can name 3 possible explanations for what the author saw: 1. The author's method of finding dependencies by looking at `ldd` output is very incomplete: `ldd` only shows unconditional shared library dependencies, but doesn't say anything about (a) plugins and libraries loaded conditionally at runtime via dlopen, (b) helper/tool executables spawned at runtime (and those executables' transitive dependencies!), (c) data dependencies, such as on common config files. Attempting to manually delete a library to see what breaks is also flawed, since the library might, for instance, be only needed for a helper executable which is only spawned under certain specific conditions that the author did not exercise. 2. It is possible that some dependencies are pulled in only because some packages are not sufficiently granular. For example, consider program A linking to library B; B belongs to package BC, which also includes helper tool C, and C links to library D. Thus, installing A causes D to be installed even thought there is no code path under which the use of A would require anything from D. The solution is to split up package BC; but for whatever reason (such as lack of time or better maintainability), the maintainer of package BC decided not to do so. 3. And occasionally, package maintainers simply get it wrong, and add dependencies that are not needed, or fail to remove dependencies which the upstream developer had required in the past but then removed (and perhaps forgot to document as no longer needed).