Linux Package Managers Are Worse Than You Think
medium.com
medium.com
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).
neofetch does use the listed dependencies, they're just weak dependencies - not required to run.
There's definitely space for improvement, but not for the reasons listed.
If you want to yolo it and let scripts run with root access from some random person, you can go use arch with the AUR
the apt thing: author should make himself familiar with https://www.debian.org/doc/manuals/debian-faq/pkg-basics.en.... and --no-install-recommends option. The "debian way" of dealing with the dependencies is different than the "slackware way" the author seems to prefer.
You can configure your debian system to use that option by default using apt.conf. If you switch to aptitude you can even ask why given package was pulled in to be installed, or why given package is in the system (aptitude why package).
About the archlinux thing: that's not archlinux, that is cachyos, please do not confuse these two. The archlinux project even has a note explaining "why" in their code of conduct: https://terms.archlinux.org/docs/code-of-conduct/#arch-linux.... (Also don't use `pacman -Sy package` to install packages, there is big red warning about that on wiki)
In the end, the overall conclusion remains: this whole dependency hell on Linux is just too messy and fragile, and we should think about a more reasonable solution, like what Android and iOS do.
I wonder if this means the success of a distribution depends more heavily on the package manager than people realize.
[1] almost/arguably