On Tue, 2008-05-06 at 10:30 +0200, Benedikt Huber wrote:
Hello,
I appreciate ongoing work with cabal-install. I've tried the latest darcs version on a clean fresh ghc, and it worked fine.
Great.
I wonder however, if there is any support (planned) for removing outdated packages. For example, when updating bytestring, I ended up with both xhtml-3000.0.2.1 and xhtml-3000.0.2.2 installed.
Is there a something like a receipt, listing the files belonging to the installation of a package ? If there were such a thing (like copy --verbose, but machine readable), uninstalling a list of outdated packages would at least be possible. I wouldn't want cabal to remove outdated packages automatically, but some support for listing and removing them seems quite important to me.
http://hackage.haskell.org/trac/hackage/ticket/234 So as you say, the way to do this would be to generate a list of files that will be installed. This can be used to later uninstall. If you want to work on this feature I can provide some advice on how to implement it. It'll need a bit of work to restructure the install code so that it actually produces a list of things to install, rather than just installing them.
Oh, and it would be nice if config fields like 'global-prefix' are mentioned in the README.
And indeed in comments in the config file itself.
In the long term, in which way should cabal-install interact with package management tools like macports ? Is it supposed to be a replacement, an alternative or a complement ?
It's not 100% clear. It is certainly not a replacement and it cannot be used to install other kinds of packages but it's also not realistic to expect all hackage packages to be supplied by every distro so we really have to aim for some kind of co-existance. cabal-install is also primarily a per-user package manager, not requiring any privileges to build and install packages. Most other package managers are global.
I thought about writing something similar as cabal-rpm for macports, but it seems better to have cabal-install handle dependency resolution and installation. Injecting a package into the pm's database after installing is imho the nicest solution. Does this make sense ?
What the best integration point is will depend on the package manager and the features you want. If you want to be able to use the package manager's dependency tracking then it has to go in at a higher level than just recording what the installed files are. Duncan