cabal-install uninstall ?
Hello, I appreciate ongoing work with cabal-install. I've tried the latest darcs version on a clean fresh ghc, and it worked fine. 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. Oh, and it would be nice if config fields like 'global-prefix' are mentioned in the README. 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 ? 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 ? Thanks, Benedikt
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
Hi Benedikt. Having a ./setup install-update-remove-outdated seems to be fine.. However how should cabal know which package versions are needed by your applications? Eg you might be working on a project requiring xhtml-3000.0.2.1 (A) and beeing not compatible with xhtml-3001 ? So this should only be done on major version numbers for packages using the x.x.x.x versioning scheme. There is another issue: If you have another package isntalled having been compiled with the old xhtml package it would be fatal to remove it because that library depends on the old version I think (not totally sure.. at least having none breaks ..) ? Has someone tried this? All package-deps are build time deps AFAIK (?) If you want this behaviour you can try nix. you can install a ghc wrapper with a set of libs. Updating a package updates all of them. However there is a drawback: nix is a whole distribution system.. You'll get glibc etc again as well. It's my tool of choice getting rid of all this update / when to delete what issues by using kind of garbage collector applied to your disk store content. Writing a tool removing all old versions isn't hard at all because all package databases are just written using show and there is a read instance. Using ghc-pkg list and filtering all lines ending with ':' (cabal is doing this) should give you a list of all package databases. Read them and check for them by yourself It looks like this. (packagedb :: [InstalledPackageInfo] ) <- fmap read $ myReadFile Creating a map sorted by names without versions and then listing/ removing old duplicates should be trivial. I've never really worked on a mac.. So maybe this all doesn't apply to you. Sincerly Marc Weber
participants (3)
-
Benedikt Huber -
Duncan Coutts -
Marc Weber