Linux Package Managers Are Worse Than You Think(medium.com)
medium.com
Linux Package Managers Are Worse Than You Think
https://medium.com/@fulalas/linux-package-managers-are-worse-than-you-think-8a106569399a
9 comments
This is wrong in so many ways and the author doesn't understand difference between various options of removing packages. Or the concept of virtual package names.
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.
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.
"You're holding it wrong"?
Not sure what you're trying to say here. This person has opinions about package managers, but also shows lack of understanding of how they and the dependencies work. Small bits of that could be improved with a better documentation, but the rest... you just need to understand something before criticising it.
If you want to use a distro then you accept the distro maintainers decisions on what's a dependency.
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
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
Somebody doesn't understand the concept of dependencies.
this is not windows where every dependency has to be bundled. It is a dependency tree.
So I'll bite:
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)
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)
These kind of complaints led me to try my hand at creating a new package manager for macOS[^1]. I really respect what the engineers at Chainguard have done with WolfiOS[^2] and tried to replicate the same - declarative package manifests which minimize the amount of dependencies. The project fizzled out after talking with some friends and realizing the futility when considering the global dominance of Homebrew.
[1]: https://github.com/willswire/cosmic
[2]: https://github.com/wolfi-dev
[1]: https://github.com/willswire/cosmic
[2]: https://github.com/wolfi-dev
Thanks for the feedback, guys! I changed some parts of the article to address the issues pointed by you.
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.
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 always found it interesting that a linux distribution is defined¹ as a package manager and a collection of packages.
I wonder if this means the success of a distribution depends more heavily on the package manager than people realize.
[1] almost/arguably
I wonder if this means the success of a distribution depends more heavily on the package manager than people realize.
[1] almost/arguably
There is no such thing as a Linux package manager.
There is the Debian package manager, or the Fedora package manager, or the Alpine package manager, because the package manager ia related to distros, not the kernel
[deleted]
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).