Ticket #234 (new enhancement)

Opened 5 years ago

Last modified 15 months ago

track installed files to allow uninstall

Reported by: duncan Owned by:
Priority: normal Milestone: cabal-install-0.16
Component: cabal-install tool Version: 1.2.3.0
Severity: major Keywords:
Cc: Misha, Aizatulin, <avatar@…>, claus, mkrauskopf, p.giarrusso@…, erikd@…, jims@… Difficulty: hard (< 1 day)
GHC Version: Platform:

Description

cabal-install needs to be able to track all the files it installs so that it'll be possible to uninstall packages.

The copy/install code should be extended to be able to generate a list of files and hashes of files that will be installed. cabal-install could use that to write out a manifest file and use that later to allow uninstalling.

One solution might be to restructure the install code to gather the source files that it would install rather than just doing it. Once that list of files is known we can copy them all in one go, and do other things like check for clashing target files and generate manifests etc.

Change History

  Changed 5 years ago by duncan

  • milestone set to Cabal-1.6

  Changed 5 years ago by guest

  • cc Misha, Aizatulin, <avatar@…> added

  Changed 5 years ago by claus

  • cc claus added

(following Duncan's suggestion to record my opinion on the importance of this ticket)

When I suggested "uninstall", 2 years ago (#106), I was very surprised that it wasn't rated as both urgent and important. The *only* reason for delaying it is that it is not something you'd want to get wrong (mostly: removing stuff you're not supposed to touch; though leaving garbage all over the place isn't nice, either).

The very first thing I check about new software is how to get out of it after I start it, and, having had some trouble with nearly-impossible-to-uninstall software, I've come to see software that installs itself without providing for proper uninstallation as deeply unprofessional, the never-use-their-stuff-again kind of experience (installing everything into a single new directory that can be removed without causing damage is okay as a minimum requirement, but if you do anything else, you'd better know how to undo it).

Doing temporary test-installs before releases (to ensure that packages are complete), forgetting/changing installation prefixes (Cabal's handling of which differs between platforms), having different compiler versions with different Cabals, Cabal evolving and putting things in different places, more and more packages on Hackage that people will want to install to try them out - all reasons why uninstall support is needed before spreading the news about Hackage/Cabal leaves potential Haskellers with a bad taste (not to mention that left-overs from previous installs bring the risk of inconsistent installations).

I really thought the importance and urgency of this ticket was self-evident but, if not, I hope this explains my point of view?-)

Btw, there seems to have been some relevant discussion in this thread

 http://www.haskell.org/pipermail/cabal-devel/2008-May/002907.html

concluding, I think, that some refactoring would be needed before tracking could work.

  Changed 5 years ago by duncan

  • milestone changed from Cabal-1.6 to Cabal-1.8

  Changed 5 years ago by SamB

  • owner set to SamB
  • status changed from new to assigned
  • severity changed from normal to major

follow-up: ↓ 7   Changed 5 years ago by igloo

A related problem is bindists:

For GHC, we want to put files like

dist/build/libHSbase-4.0.a

in bindists, so that to install a bindist we can just run (more or less) "Setup install". However, we don't want to include files that don't get installed like

dist/build/Data/String.o

as that bloats the bindist size, so we can't just include the whole dist/ directory. Currently we break the abstraction and pick out the files that we want when creating the bindists, but it would be nice to be able to ask Cabal what files it needs to use in order to do the installation.

in reply to: ↑ 6 ; follow-up: ↓ 8   Changed 5 years ago by duncan

Replying to igloo:

A related problem is bindists:

Why not just construct the bindist from the result of Setup copy --destdir=image ?

in reply to: ↑ 7   Changed 5 years ago by igloo

Replying to duncan:

Replying to igloo:

A related problem is bindists:

Why not just construct the bindist from the result of Setup copy --destdir=image ?

That puts paths into wrapper scripts, package.conf, etc.

  Changed 4 years ago by mkrauskopf

  • cc mkrauskopf added

  Changed 3 years ago by duncan

  • owner SamB deleted
  • status changed from assigned to new
  • ghcversion 6.8.2 deleted
  • component changed from Cabal library to cabal-install tool

  Changed 3 years ago by Tobu

I am also interested in this. I wasn't able to find what code was copying the files from reading the source (sad), but mailing list threads provided more information:

The September thread is helpful. Also note that the manifest should log ghc-pkg package registrations.

  Changed 3 years ago by Blaisorblade

  • cc p.giarrusso@… added

  Changed 22 months ago by mcandre

Please, please, please add this.

  Changed 19 months ago by erikd

  • cc erikd@… added

follow-up: ↓ 16   Changed 19 months ago by Jim Stuttard

cc jims@…

in reply to: ↑ 15   Changed 19 months ago by Blaisorblade

Replying to Jim Stuttard:

cc jims@…

That does not work; instead, find the "Add to Cc" checkbox in the "Change Properties" form, below the comment box.

  Changed 19 months ago by Jim Stuttard

  • cc jims@… added

  Changed 15 months ago by kosmikus

  • milestone changed from Cabal-1.8 to cabal-install-0.16
Note: See TracTickets for help on using tickets.