nice little Cabal gotcha

[Duncan Coutts]

On Mon, 2008-04-14 at 16:08 +0700, Peter Gammie wrote:

> >> Can you expand on your squeamishness?
> >
> > We should not delete files we don't know that we own. We only know we
> > own files we're installing. So we cannot delete anything.
> 
> As I said before, I disagree. Directories like ~/lib/package/ghc-6.6.1  
> are clearly Cabal-directories. (Please insert some $'s to make that  
> suitably relative). All sorts of gunk piles up in there while  
> developing. When hacking libs, one really wants "install" to mirror  
> what one has just built.

It may look that way but what if someone configures to use ~/lib
directly? The directory structure we use is just a default, it's all
completely configurable. We cannot rely on 'owning' anything.

> Consider this sequence:
> 
> Step 1:
> 
> configure -p
> build
> install
> 
> Step 2:
> 
> <change implementation but not API>
> clean
> configure
> build
> install
> 
> Now the profiling libs are out of date, Cabal "owned" them before but  
> not now...

Sure I see the problem.

> Also consider:
> 
> <Step 1>
> <delete some modules from blah.cabal>
> configure
> build
> install
> 
> and now we may have some .hi files orphaned by Cabal.
> 
> Ditto for documentation.

Yep.

> > Only a package manager can do that because it knows what files  
> > belong to
> > the package we're replacing. Of course cabal-install is a package
> > manager of sorts so if it tracked what files belonged to packages it
> > installed then it'd know what files to remove when it replaced  
> > packages.
> 
> This is a non-solution: I've *changed* what is owned by the package.

Exactly! That's just why we need a package manager. It remembers what
files belonged to the Foo package before and now that we're installing
Foo again it knows that we're *replacing* Foo, so it's safe to delete
all the old files that belonged to the Foo package and install all the
new Foo files (and remember them for later).

> I claim this is all so arbitrary that it is better for Cabal to simply
> throw everything out... the alternative is endless prompts: "do you  
> really want me to clobber this file you don't care about?" or dodgy  
> behaviour in corner cases.

This behaviour is completely consistent with all other build systems I
know of. We really need package managers to solve the problem.

> BTW can I really ask Cabal to install a lib into:
> 
> ~/
> 
> and have all files end up there? (i.e. no ghc-6.6.1 etc. subdirs?)

Yes you can do that.

> If not, we are arguing past each other.


> Would be nice. You need debian-style "remove using old .cabal"  
> "install using new .cabal" persistence though, in case the .cabal has  
> changed.

Well, as I said, the package manager just needs to remember the set of
files that belong to each installed package.

A related problem is that we need to solve this problem at least within
the ./dist/ directory. One of your examples was changing a .cabal file
to add/remove a module. Currently we would not delete any existing .hi
or .o files within ./dist/. As it happens for .o and .hi we copy out
exactly the ones we need, but that's not the case for the documentation
for example so we might end up copying stale .html files. To do that
properly we'd need to track generated files much more closely.

Duncan