This can be particularly useful for large enterprises whose operating systems typically consist of hundreds or even tens of thousands of distinct software packages.
[citation needed] Early package managers, from around 1994, had no automatic dependency resolution[3] but could already drastically simplify the process of adding and removing software from a running system.
[4] By around 1995, beginning with CPAN, package managers began doing the work of downloading packages from a repository, automatically resolving its dependencies and installing them as needed, making it much easier to install, uninstall and update software from a system.
[5] A software package is an archive file containing a computer program as well as necessary metadata for its deployment.
On Microsoft Windows systems, this is also called "DLL hell" when working with dynamically linked libraries.
[7] Modern package managers have mostly solved these problems, by allowing parallel installation of multiple versions of a library (e.g. OPENSTEP's Framework system), a dependency of any kind (e.g. slots in Gentoo Portage), and even of packages compiled with different compiler versions (e.g. dynamic libraries built by the Glasgow Haskell Compiler, where a stable ABI does not exist), in order to enable other packages to specify which version they were linked or even installed against.
For example, a local administrator may download unpackaged source code, compile it, and install it.
There are exceptions to this that usually apply to kernel configuration (which, if broken, will render the computer unusable after a restart).
[18] App stores can also be considered application-level package managers (without the ability to install all levels of programs[19][20]).
[21][20] They are usually extremely limited in their management functionality, due to a strong focus on simplification over power or emergence, and common in commercial operating systems and locked-down “smart” devices.
They give users the ability to apply security and compliance metrics across all artifact types.
Yum extends the functionality of the backend by adding features such as simple configuration for maintaining a network of systems.
By the nature of free and open source software, packages under similar and compatible licenses are available for use on a number of operating systems.
One typical difference between package management in proprietary operating systems, such as Mac OS X and Windows, and those in free and open source software, such as Linux, is that free and open source software systems permit third-party packages to also be installed and upgraded through the same mechanism, whereas the package managers of Mac OS X and Windows will only upgrade software provided by Apple and Microsoft, respectively (with the exception of some third party drivers in Windows).
Their rationale is to allow users to manage the software dependency on data, such as machine learning models for data-driven applications.
A typical example of a data dependency management frameworks are Hugging Face, KBox,[31] among others.
Ian Murdock had commented that package management is "the single biggest advancement Linux has brought to the industry", that it blurs the boundaries between operating system and applications, and that it makes it "easier to push new innovations [...] into the marketplace and [...] evolve the OS".