uninstalling libraries

Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

uninstalling libraries

Evan Laforge
For a very long time, I've used a local script to uninstall libraries.
Initially it was very simple: use ghc-pkg field to find and remove
library-dirs, import-dirs, and haddock-html, and call ghc-pkg
unregister.

It served well for a long time, but eventually I got tired of copy
paste games and extended it to be able to recursively delete
dependents too.  Unfortunately now it's no longer so simple.  The main
problem is that the only way I know to find dependents is to ghc-pkg
unregister, and see what the error message complains about.  That's
obviously pretty bad, since by that time you've already unregistered,
so it's too late to back out.  The non-atomic nature of unregister+rm
has always caused problems anyway, since if unregister succeeds, but
the remove fails, we are stuck with a partial install.  Recursive
delete is too error prone, so I reverted that.

And then I discovered that hmatrix helpfully includes /opt/local/lib
and /usr/local/lib in its library-dirs, so clearly just deleting
whatever the package tells me is not very safe.  All this has led me
to believe uninstalling packages is not so simple, and maybe there
should be an actual real way to do it, not everyone hacking up their
own dangerous shell scripts.

So... is there?  Should there be one?  Is there interest in one?  How
do other people uninstall libraries?  Is there a better interface to
the pkg db than ghc-pkg?  Is there a better way to find dependents
than ghc-pkg unregister?
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: uninstalling libraries

Evan Laforge
On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery <[hidden email]> 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.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: uninstalling libraries

Brandon Allbery
cabal and stack, and in the case of stack, cabal new-build, and possibly cabal sandboxes, you probably shouldn't be trying to uninstall.

And yes, the data lines are telling ghc what to compile / link with, not files but command line inclusions. And this will be especially messy on OS X because of the need to group .dylibs together to avoid making the link commands section too large with multiple RPATH entries. (Which will also complicate uninstallation there.)

On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge <[hidden email]> wrote:
On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] uninstalling libraries

Dan Burton
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" <[hidden email]> wrote:
cabal and stack, and in the case of stack, cabal new-build, and possibly cabal sandboxes, you probably shouldn't be trying to uninstall.

And yes, the data lines are telling ghc what to compile / link with, not files but command line inclusions. And this will be especially messy on OS X because of the need to group .dylibs together to avoid making the link commands section too large with multiple RPATH entries. (Which will also complicate uninstallation there.)

On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge <[hidden email]> wrote:
On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery <[hidden email]> 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
[hidden email]                                  [hidden email]
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.



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] uninstalling libraries

Evan Laforge
On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton <[hidden email]> wrote:
> 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.

I'm usually backing out of a version so I can install something else.
I always keep just one version of each library installed.  It's less
clutter, and I never have any question about what package is linked to
what version of what other package.

Maybe it's not the official way to do things, but it's probably the
reason I've never encountered cabal hell.  Back in the day, of course,
it was the only option.  Nowadays we have cabal sandbox, but global
packages are still simpler and more convenient.  Maybe the new cabal
install will improve on the situation, but it seems hard to beat the
convenience, and doesn't provide the guarantee that there's no version
skew anywhere.  But, I'm not the only one with a single version
policy, Google does too.

Anyway, if there's no interest in robust uninstallation, I'll just
continue using my script, with a few extra hacks to avoid deleting
/usr/local/lib.  Except that one hiccup it's actually worked fine for
the last 15 years or so.  For me, making a better API to the package
db than ghc-pkg would probably do well enough.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] uninstalling libraries

Dan Burton
The point at which I find a "single version policy" difficult is when I'm trying to contribute to disparate packages or projects, with differing maintainers and version requirements. One person wants to use the latest, while another hasn't upgraded yet. Sandboxing is the only sane way to work on two such projects simultaneously.

But if you, like Google, have enough control over all the projects worked on in order to dictate a single version policy, then that approach can certainly have its benefits. I'm not sure many people consider themselves in such a position, hence the pervasive assumption that sandboxing will be involved.


On Nov 13, 2017 14:45, "Evan Laforge" <[hidden email]> wrote:
On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton <[hidden email]> wrote:
> 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.

I'm usually backing out of a version so I can install something else.
I always keep just one version of each library installed.  It's less
clutter, and I never have any question about what package is linked to
what version of what other package.

Maybe it's not the official way to do things, but it's probably the
reason I've never encountered cabal hell.  Back in the day, of course,
it was the only option.  Nowadays we have cabal sandbox, but global
packages are still simpler and more convenient.  Maybe the new cabal
install will improve on the situation, but it seems hard to beat the
convenience, and doesn't provide the guarantee that there's no version
skew anywhere.  But, I'm not the only one with a single version
policy, Google does too.

Anyway, if there's no interest in robust uninstallation, I'll just
continue using my script, with a few extra hacks to avoid deleting
/usr/local/lib.  Except that one hiccup it's actually worked fine for
the last 15 years or so.  For me, making a better API to the package
db than ghc-pkg would probably do well enough.


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] uninstalling libraries

Evan Laforge
To be fair, it's not absolute.  I have found cabal sandbox useful to
compile things thing tons of dependencies, like pandoc.  And if I
wanted to contribute to something with out of date version
requirements (and the first step is not helping them upgrade, for
whatever reason), then surely I'd go ahead and make a sandbox for
that.  It hasn't really come up though.  I'm certainly not trying to
push this as The Solution, that's a bigger windmill than just
uninstalls :)

On Mon, Nov 13, 2017 at 4:56 PM, Dan Burton <[hidden email]> wrote:

> The point at which I find a "single version policy" difficult is when I'm
> trying to contribute to disparate packages or projects, with differing
> maintainers and version requirements. One person wants to use the latest,
> while another hasn't upgraded yet. Sandboxing is the only sane way to work
> on two such projects simultaneously.
>
> But if you, like Google, have enough control over all the projects worked on
> in order to dictate a single version policy, then that approach can
> certainly have its benefits. I'm not sure many people consider themselves in
> such a position, hence the pervasive assumption that sandboxing will be
> involved.
>
>
> On Nov 13, 2017 14:45, "Evan Laforge" <[hidden email]> wrote:
>
> On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton <[hidden email]>
> wrote:
>> 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.
>
> I'm usually backing out of a version so I can install something else.
> I always keep just one version of each library installed.  It's less
> clutter, and I never have any question about what package is linked to
> what version of what other package.
>
> Maybe it's not the official way to do things, but it's probably the
> reason I've never encountered cabal hell.  Back in the day, of course,
> it was the only option.  Nowadays we have cabal sandbox, but global
> packages are still simpler and more convenient.  Maybe the new cabal
> install will improve on the situation, but it seems hard to beat the
> convenience, and doesn't provide the guarantee that there's no version
> skew anywhere.  But, I'm not the only one with a single version
> policy, Google does too.
>
> Anyway, if there's no interest in robust uninstallation, I'll just
> continue using my script, with a few extra hacks to avoid deleting
> /usr/local/lib.  Except that one hiccup it's actually worked fine for
> the last 15 years or so.  For me, making a better API to the package
> db than ghc-pkg would probably do well enough.
>
>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users