On Sun, Jul 20, 2008 at 11:39 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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 ?
Yes. Just out of curiosity, are you interested in doing the possibly substantial work to make this happen? Also, how does your proposed solution compared to the solutions for this problem used by package management systems, e.g., Debian (apt/dpkg), Redhat (in rpm), etc. ? -- william --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
