Hi guys,
I don't think uninstalls are as hard as is made out here, at least not if
you restrict yourself to a limited set of guarantees. Does EB not install
each package to its own prefix? Why can't you store DAG info with the
installation?
Spack actually does this and supports uninstall:
http://scalability-llnl.github.io/spack/basic_usage.html#spack-uninstall
And it knows where all the spack-installed packages live, because they're
assigned unique specs at install time, which translate to unique install
prefixes. If you uninstall something, right now, it just loads the DAG
info for all the installed packages, and checks whether the package to be
installed is a sub-DAG of any of the other packages. That's probably more
laborious than it needs to be but it's fairly simple python code:
https://github.com/scalability-llnl/spack/blob/master/lib/spack/spack/pack
age.py#L621
It will warn the user if anything depends on the package to be
uninstalled. You can also supply --force if you don't care about being
destructive.
Spack has a slightly more regimented naming convention than EB, but can't
you just store the easyconfig names for all dependents someplace in the
install prefix at install time? Then you can pretty easily see if any of
those are installed. I guess that wouldn't be robust to EB version
updates, but it would be a start.
FWIW, this is also done for python module installations. If you activate
a python extension, you can then deactivate it later and it'll be unlinked
from the python prefix:
http://scalability-llnl.github.io/spack/basic_usage.html#extensions-python
-support
That's done using essentially the same mechanism.
-Todd
On 3/10/15, 1:49 PM, "Kenneth Hoste" <[email protected]> wrote:
>Hi Kilian,
>
>On 10/03/15 18:32, Kilian Cavalotti wrote:
>> On Tue, Mar 10, 2015 at 10:18 AM, Stuart Barkley <[email protected]>
>>wrote:
>>> Is there a good way to see a dependency tree with easybuild (I'm now
>>> running 2.0.0)? I'm trying to reconcile different dependency
>>> requirements for my large build and am finding it difficult to
>>> determine what packages are requiring other packages.
>> +1 on that. And that would be a good start to implement an "uninstall"
>> option, as described in
>> https://github.com/hpcugent/easybuild-framework/issues/590
>> BTW, this was supposed to be part of EB 2.0 (cf. #1000), but it
>> apparently got postponed.
>
>Just to clarify: having support for uninstalling installations performed
>with EasyBuild was never part of the release plan for EasyBuild v2.0
>(see the description in
>https://github.com/hpcugent/easybuild-framework/issues/1000), it was
>just mentioned by someone that this may be interested/useful to have it
>in there.
>
>There are a couple of issues that make support for uninstalling stuff
>difficult, or even impossible, to get right (as was discussed during the
>last hackathon, I believe):
>
>- it requires support for enabling reverse dependency tracking (not
>trivial, but doable)
>- it requires to be able to generate reverse dependency info for an
>existing install base; either the reverse deps information is complete,
>or useless (not that easy)
>- even with reverse dependency tracking in place, there's never a
>guarantee that something can be removed without damaging other
>installations that depend on what's being removed (consider software
>stacks installed in different installation prefixes, but with
>cross-dependencies)
>
>The main issue is that nobody has really picked up on this yet, so no
>work is being done on it actively.
>Unfortunately, features (and the documentation to go with them) don't
>appear out of thin air. ;-)
>
>The guys in Jülich have done some scripting related to this (see
>https://github.com/hpcugent/easybuild-framework/pull/1190), some ideas
>can be stolen from there to incorporate into the EasyBuild framework to
>add support for uninstalling stuff, but it's never going to be perfect
>(in the sense that it'll probably always need to be combined with
>--force together with getting a warning thrown at you when using
>--uninstall).
>
>
>regards,
>
>Kenneth
