> All the hard work of figuring out dependencies, avoiding cycles, etc is done OUTSIDE the OS by the repository maintainers
Your typical package manager will build a recursive and reverse dependency database, resolve version conflicts, detect cycles, and suggest alternative dependencies and recommended or optional packages.
Here's the official PKGBUILD used by Arch for ffmpeg as an example. There's not a single version qualifier in sight, and no other files are needed to build and install the package... from source.
It's not exactly trivial, but FOSS OSs have been doing this for decades and have hundreds of thousands of packages. It's a vast improvement over having 28 copies of the openssl dll on your average Windows machine, all out of date.
>Your typical package manager will build a recursive and reverse dependency database, resolve version conflicts, detect cycles, and suggest alternative dependencies and recommended or optional packages.
All that is done outside the OS by third party code. Also, you have to stay within that particular package manager to get those benefits. With different distros you have to stay within whatever package manager they ship with. There is no common "linux" code that allows this to happen (Indeed you can implement a package manager on any OS). If you go around installing rpms manually or installing/building via source, it is fairly trivial to bork your package managers state. For e.g. - If you manually build/install a dependency that one particular package in the repo says should be of a different version..
But yes, in general all mainstream Linux distros do ship with many tools/libs - X.org, GTK, Gnome, whatnot. Are all of them part of the OS? I see the package manager as a third party tool much like the rest since it does not interact with the core OS in any deep sense. But maybe my point of view comes from being a Linux user since 1996 with Slackware..
LFS is not a distro. It's documentation to build your own distro.
Xorg, GTK and all the irrelevant stuff you mention have nothing to do with it.
If you remove yum/rpm or dpkg/apt from the system it simply stops working. Also
you can't replace apt with yum and vice versa, as you can with KDE vs GNOME.
Package management is a very integral part of a system, that's why we separate
distros by their packaging system(apt-based, rpm-based, emerge, etc...)
You keep spouting nonsense and you keep being voted down, yet your insistence
in showing your ignorance is astonishing.
Your typical package manager will build a recursive and reverse dependency database, resolve version conflicts, detect cycles, and suggest alternative dependencies and recommended or optional packages.
Here's the official PKGBUILD used by Arch for ffmpeg as an example. There's not a single version qualifier in sight, and no other files are needed to build and install the package... from source.
https://projects.archlinux.org/svntogit/packages.git/tree/tr...
It's not exactly trivial, but FOSS OSs have been doing this for decades and have hundreds of thousands of packages. It's a vast improvement over having 28 copies of the openssl dll on your average Windows machine, all out of date.