Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

track installed files to allow uninstall #227

Open
bos opened this issue May 24, 2012 · 17 comments

Comments

@bos
Copy link
Contributor

commented May 24, 2012

(Imported from Trac #234, reported by @dcoutts on 2008-02-11)

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.

@bos

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2012

(Imported comment by claus on 2008-02-11)

(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.

@bos

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2012

(Imported comment by @igfoo on 2008-06-25)

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.
@bos

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2012

(Imported comment by @dcoutts on 2008-09-01)

Replying to @igfoo:

A related problem is bindists:

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

@bos

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2012

(Imported comment by @igfoo on 2008-09-02)

Replying to @dcoutts:

Replying to @igfoo:
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.
@bos

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2012

(Imported comment by Tobu on 2008-09-02)

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:

  • [http://www.haskell.org/pipermail/cabal-devel/2008-May/002817.html](http://www.haskell.org/pipermail/cabal-devel/2008-May/002817.html)
  • [http://www.haskell.org/pipermail/cabal-devel/2006-August/000152.html](http://www.haskell.org/pipermail/cabal-devel/2006-August/000152.html)
  • [http://www.haskell.org/pipermail/cabal-devel/2006-September/000168.html](http://www.haskell.org/pipermail/cabal-devel/2006-September/000168.html)
The September thread is helpful. Also note that the manifest should log ghc-pkg package registrations.
@bos

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2012

(Imported comment by @mcandre on 2010-01-24)

Please, please, please add this.

@bos

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2012

(Imported comment by Jim Stuttard on 2011-07-19)

cc jims@…

@bos

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2012

(Imported comment by @Blaisorblade on 2011-10-29)

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.

@gregorycollins

This comment has been minimized.

Copy link
Member

commented Jan 27, 2013

After discussing with @tibbe, removing the "important" flag here, which should be reserved for things we really want to prioritize fixing sooner rather than later.

@GeorgeCo

This comment has been minimized.

Copy link

commented Sep 16, 2014

My issue. #2108, was closed as a known issue, i.e. this one, but this doesn't mention my case so I think it is worth making it explicit, currently ghc-pkg list contains no record that I have installed certain packages such as cabal-install or alex. Consequently cabal install of such a package just "reinstalls" the whole package. I'm not convinced my issue is the same as this one. I believe my issue is a regression

@Blaisorblade

This comment has been minimized.

Copy link
Collaborator

commented Sep 17, 2014

My issue. #2108, was closed as a known issue, i.e. this one, but this doesn't mention my case so I think it is worth making it explicit, currently ghc-pkg list contains no record that I have installed certain packages such as cabal-install or alex. Consequently cabal install of such a package just "reinstalls" the whole package. I'm not convinced my issue is the same as this one. I believe my issue is a regression

This was answered in #2108 (comment), and I agree. And (unfortunately) it's not a regression, this never worked for executables without a library.

This issue focuses about a different aspect, but tracking installed files would work for all packages, with or without libraries. The extra point (which might deserve a separate issue) is that checking whether a package is installed should then stop using ghc-pkg and use cabal's database.

@BardurArantsson

This comment has been minimized.

Copy link
Collaborator

commented Jun 25, 2015

Cabal-install is not a package manager. IMO this is a non-goal and the issue should be closed.

(Btw, sandboxes can already serve as a workaround if you really want something that's trivial to remove.)

@23Skidoo

This comment has been minimized.

Copy link
Member

commented Jun 26, 2015

Cabal-install is not a package manager. IMO this is a non-goal

I don't think there's any deep technical or philosophical reason for not having this feature, it's just that it was never implemented.

@BardurArantsson

This comment has been minimized.

Copy link
Collaborator

commented Aug 22, 2015

Even if it were easily or even trivially(!) implementable... this is not the remit of not-a-package-manager, IMO. Also, given lack of activity on this issue, I still suggest closing this issue.

(Anyone is still free to implement this if they want. I just think that having this issue lying around is pure noise.)

@mietek

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2015

I disagree both with your premise and your conclusion. Implementing this seems necessary to solve issues such as #220, #779, and #1896.

@BardurArantsson

This comment has been minimized.

Copy link
Collaborator

commented Aug 28, 2015

Can you please explain how this is necessary for implementing any of the issues you mentioned? (This issue is about tracking files -- or at least originally was about that.)

@BardurArantsson

This comment has been minimized.

Copy link
Collaborator

commented Aug 28, 2015

Also... what, specifically, do you disagree with?

EDIT: I should say... which premise do you disagree with? (Obviously, if you disagree with a premise then any conclusion is void :))

@ezyang ezyang modified the milestones: Obsoleted by nix-local-build, _|_ Aug 16, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.