Hi folks,
Looking at the way that sage builds and installs its packages, I
didn't see an easy way to remove an optional package (say in case it
breaks something, or you don't need it anymore) ; has it been
considered to use something like GNU stow or my favorite, graft
(http://www.gormand.com.au/peters/tools/graft/graft.html) ?
The general idea is to have each package installed inside its own
directory (say, $SAGE_ROOT/spkg/graft/package-1.0.0-p0), and to only
put the directory structure with links to the files inside $SAGE_ROOT/
local. It has plenty of advantages :
- trivial to see what is installed (that is just the list of
subdirectories of graft/ to which there are symlinks).
- easy to deactivate a package (just remove the links) without
removing the actual files, so that one can re-activate it later.
- easy to remove a package.
- clean upgrades of packages : just remove the previous version, and
be sure that no obsolete files remain in local/. Also one can quickly
switch between two versions of a package for debugging purposes.
- mixing packages installed as they are currently with grafted
packages poses no difficulty, they can cohabit peacefully.
Packages need to be configured with --prefix=$SAGE_ROOT/local,
installed with DESTDIR=somewhere, and then somewhere/$SAGE_ROOT/local
has to be renamed to $SAGE_ROOT/spkg/graft/packagename-v.er.si-on
before graft (or whichever one) is called to put the links in place.
There are two drawbacks to the system :
- it creates LOTS of symlinks (one per regular file). Not sure of the
gravity of that one.
- (the big one) in principle, CFLAGS etc will look inside $SAGE_ROOT/
local and happily follow the symlinks. But some packages may be too
eager and figure out the real path to the real file in graft/
packagename-..., and then look for them there instead of in $SAGE_ROOT/
local at runtime. Then if the library is upgraded and the old one
removed, even though the links in $SAGE_LOCAL are of course upgraded
in the process, things might break.
This is quite rare I believe (I only saw it when running a version of
gcc installed this way, which figures out the current location of the
executable at runtime and puts it inside the built executables as an
RPATH), and of course the fix is easy, simply unlink the previous
version but keep the necessary old files ...
So, is that worth looking into ?
/vincent
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
