Windows and OS X users wonder why Linux users seem to make such a big fuss over "package management". On Windows, "Add/Remove Programs" attempts to provide a unified interface for installing or removing applications, though it does nothing to manage dependencies or upgrades. That means you can put your Windows machine in an inconsistent (read: broken) state simply by installing or removing an application. The Windows solution of system restore points treats the symptoms rather than the problem. Users should not be able to put Windows in a state in which it is necessary to restore to a previous state. Moreover, system restore points are not reliable so they can lull users into a false sense of security.

On OS X, it's even worse. There is no unified "Add/Remove Programs" like thing so removing an application is more complicated than it should be, especially for an operating system that prides itself on UX (User Experience). The OS doesn't provide any way to manage dependencies either, at least not on the "desktop" version that I've used, so just like in Windows, upgrading or removing software can put your machine in an inconsistent state. This isn't some theoretical thing. It happens even to the much-vaunted OS X.

On Linux, at least with distributions that use some sort of a package manager, which is most of them, there is a unified interface for installing, upgrading, or removing packages. Dependency management is handled by that system. While it isn't perfect, it is very rare that you'll manage to get your operating system in an inconsistent state simply by installing, upgrading, or removing an application. People who haven't used Linux seem to think this is all so complicated and that one has to type "arcane" commands to make all this happen. Nothing could be further from the truth in a modern Linux distribution. In fact, Linux has had this facility for at least five years or more.

The screen shots below are from a GUI front-end to the package manager in Fedora 10. There are literally tens of thousands of applications (a.k.a. packages) available through that interface and it is as simple as selecting one and choosing to install, upgrade, or remove it. Below, I illustrate two cases, the first removing a package that is currently installed on the system and the second, installing a package that is not currently installed.

Removing a Package

I already have the excellent PostgreSQL database server installed on this machine. Let's say that I'm a newbie who for whatever reason decides to remove the PostgreSQL client libraries. I don't understand all this complicated "dependency" stuff so I just click on the the little "minus" icon and the "Apply" button.

I'll be asked to confirm my action.

If I accept, the package manager will resolve dependencies.

It will quite sensibly tell me that the PostgreSQL server has to be removed in order for the PostgreSQL client libraries to be removed. Note that if I wanted to remove the PostgreSQL server, the client libraries could remain. The server has a dependency on the client libraries but the client libraries don't have a dependency on the server.

I can now decide if I want to remove both or not.

Installing a New Package

Let's say that I wanted to install the very popular Ruby on Rails web development framework on this machine. I know I don't have that installed because I prefer the excellent Django web development framework so it is a perfect example.

I don't know the exact name of the package so I type "rails" in the search field and get a match. I click on the plus icon and click on the "Apply" button to tell the package manager that I want to install this package.

Again, I'll be asked to confirm my action.

If I accept, the package manager will resolve dependencies.

I will be presented with a list of all the dependencies that the package manager must install to satisfy my choice and if I accept the list, it will fetch those packages from the configured packages repositories and work out the order in which to install to satisfy the dependencies. Those repositories could be on-line public repositories, a local CD or DVD, or as is the case in our environment, a private mirror of the on-line repositories so that we can deploy systems via Cobbler.

Conclusion

I know Windows and OS X both have bits and pieces of what I described above but they are lacking major pieces, at least with the out-of-the-box installations of both. Everything I've described above is available with what comes "in-the-box" for Fedora, Red Hat, or derivatives. Other Linux distributions have similar capabilities, though they differ in the details.