Cabal and GHC

[Oren Ben-Kiki]

It seems that allowing multiple installed versions would get you
ambiguities though...

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121122/869d0a4c/attachment-0001.htm>