In the simplest case, if I have two versions of package foo installed, and I install a package bar that is compatible with both, which one should cabal choose? Presumably the latest, I guess?

In the general case, what we have is a DAG of packages. What is installed is a subset of the DAG, with specific version numbers for each package. Assuming no trickery, what is installed is consistent - a single version for each package such that each connected DAG component is consistent with the packages requirements.

The "really fun" stuff in cabal is when two different disconnected DAG components become connected, due to a package requiring something from each of the components. Even if the original two components were consistent, the combined DAG need not be. This is when you get the wailing and gnashing of teeth.

If you allow only one version of a package to be installed, this forces the user to re-install a whole bunch of "innocent bystander" packages to restore consistency to the *whole* now-connected larger DAG component (*not* just the part that the new package depends on). While this is a PITA, it is at least well defined (assuming one only upgrades packages, never downgrades them).

AFAIK, cabal doesn't do this right now, and IMVHO this is a source of a lot of the pain using it. BTW, the same problem occurs when one un-installs a package, or updates/downgrades to a different package version, etc.; it should be easy to un/re-install all affected packages, but AFAIK cabal doesn't make it easy. For that matter, it should be easy to un-install an ("application") package and all ("library") packages that were only installed to support it, and aren't used by any other package ("apt" does that and it is a "very cool" feature).

At any rate, if we allow multiple versions of a package to be installed, then you might have several viable candidates for installing a new package, each re-using some of the existing packages, and forcing the installation of newer/older versions of some others. The simplest thing to do would be to only install newer versions of existing packages, which would give similar results to the single-installed-version case. So, you need to solve the same automation problem as for the single-installed-version case, plus add the ability to manage multiple versions. The same considerations hold for uninstalling a package version.

For this reason, I think that before we hop on the multiple-installed-versions wagon, it is worth taking a long hard look at automating *all* aspects of automatic-transitive-closure of *all* the current cabal operations. This is what most package managers do (Debian's "apt", etc.) and they seem to be handling the "DLL hell" pretty well.

Whatever the solution is, I agree cabal does need fixing...

Oren Ben-Kiki