On Sun, Jul 20, 2008 at 11:59 PM, mabshoff <[EMAIL PROTECTED]> wrote: > > On Jul 20, 2:39 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: >> Hi folks, > > Hi Vincent, > >> 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 problem of removing optional packages has some up before, but > there is no solution. > >> 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. > > I am more than sure that a lot of packages do not honor DESTDIR. Those > can be likely fixed. > > There is also a lot of code that does not use configure && make && > make install. How is that dealt with? What about python packages? Or > do you only want to deal with optional packages?
Yes, I think he definitely claims to *only* want to deal with optional packages. > >> 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, it is certainly something that sounds interesting enough to play > with, but while it likely works on Unix/Linux and OSX I doubt it will > work on native Windows. So that could be a major showstopper to its > adaption. It could also mean that we just don't deploy it on windows, i.e., on windows one doesn't have an "uninstall optional package" option. William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
