
I also lean towards the "you shouldn't be trying to uninstall" mentality.
But it's worth discussing.
What is the motive for uninstalling? Is it to upgrade to a new version? To
narrow hoogle search results? For these, our sandbox tooling should allow
for upgrades or selective querying without having to manually uninstall. If
it's just because you want the hard drive space back, then I don't really
have anything for that.
On Nov 12, 2017 20:55, "Brandon Allbery"
On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery
wrote: This is something of a nasty problem, considering that storing uninstall information separately is not particularly robust. Perhaps ghc-pkg should, if it doesn't already, support extension fields that e.g. cabal can use to store uninstall information. (But even that potentially has problems, given that people are known to copy package registration information between package databases. If there is uninstall information in there, what happens if someone uninstalls via one or the other copy?)
Aren't packages only allowed to install a restricted set of things into a restricted set of places? We have the code (.hi, .a, .so, etc., in import-dirs / library-dirs), possibly library-specific data (I assume that's data-dir), and haddock (haddock-html and haddock-interfaces, awkwardly in separate places).
One problem is that I don't fully understand what those fields mean, is there documentation somewhere? And then the fact that these are all plural so presumably you could have a lot of them, what is that for?
I'm guessing library-dirs means something like "put this on your -L line" so it's clearly a mistake to interpret that as "here's where I put the library", and you'll have things like /usr/local/lib if you need to link external libraries.
Is there any more complicated install plan than put *.a, *.so, *.hi in $root/lib/$ghc/$package-$id, put haddock in $root/share/doc/$ghc/$package, put ad-hoc junk in $root/share/$ghc/$package? I assume there must be, but who's doing that and why? If it's OS packages, then they have their own uninstall mechanisms, presumably not ghc's problem.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.