Fixing "breaking packages"

[Max Bolingbroke]

On 1 March 2013 14:15, Ian Lynagh <ian at well-typed.com> wrote:
> On Fri, Mar 01, 2013 at 03:02:41PM +0100, Jan Stolarek wrote:
>>
>> fixing things. I would like cabal to prevent such things from
>> ever happening, the same way that
>> Linux rpm/deb managers keep packages on the system in a consistent state.
>
> There's one big difference here: rpm/dpkg are only used to install
> things by the system administrator. But in the case of Cabal, a user
> could install 'mypackage' (in their user package database) and the next
> day the sysadmin could install a different instance of 'mypackage' in
> the global database.

I thought that "cabal install" should be viewed as installing an
instance of the requested package by recompiling the whole transitive
closure of dependencies from scratch, in a sort of NixOS-like way.
Given this view, Cabal's reuse of already compiled and installed
packages is purely an optimization that can prevent it from
recompiling some things if it is absolutely certain that doing so is
unnecessary. The problem then is just that Cabal is currently brokenly
unable to handle multiple instances of an installed package with the
same name and version. In this view, the existence of local and global
databases is straightforward: packages should always be installed in
the most-accessible DB to which you have write permissions (for
maximum sharing) and should be sourced from whichever is convenient
when they are required.

There are two complicating factors:
 1. Some packages cannot be recompiled by the user (such as base)
which breaks the mental model a bit. This s probably not too
important.
 2. In this view, does "cabal install mylibrary-1.1" actually do
anything useful? The very next program you write that tries to link
against mylibrary-1.1 may end up requiring a differently-compiled
version because of its own dependency constraints. Of course, "cabal
install myexe-1.1" is perfectly useful and well defined, and it should
be the case that if "cabal install my-dep-1 my-dep-2 ... my-dep-N"
immediately preceds "cabal build" of a package with dependencies
(my-dep-i) then compilation of that package should proceed without
requiring any dependencies to be recompiled.

It seems to me that the ideal mental model for "cabal install
mylibrary-1.1" is that it appends to a global mapping from package
name to version which are essentially the packages that are available
when you do "ghc -package mylibrary" and when using ghci. Cabals
promise should be that it adds the requested package to the global
mapping and then recompiles *everything* on your system as necessary
in order to make it possible for every package in that global mapping
to be imported simultaneously into a GHCi session.

This seems like a vaguely sensible model of how things *should* work
to me, unless I've overlooked some horrible complication. I know that
Duncan is pretty keen on Nix so this the above plan may even be his
final intention. But of course, saying all that is one thing, but
finding the time to implement it quite another...

Max