On Jul 20, 3:27 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> 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.
Sure, but biopython and trac are for example two optional packages
that are python. We can achieve the same solution as graft by setting
the prefix during the build process and then expanding PATH and
LD_LIBRARY_PATH during the startup of Sage. That way can we can move
over the optional spkgs that work. But there is the obvious problem
that installs with existing optional spkgs that are upgraded will end
up with loads of files in SAGE_LOCAL as well as SAGE_LOCAL/
FOO_OPTIONAL. I think it is worth playing with since the removal of
optional spkgs is good. That way we could probably also easily deal
with the doctest optional spkgs more fine grained problem since we
will have to write some kind of infrastructure that deals with what
optinal spkg is installed. For commercial code like MMA and Maple we
could create some fake optional spkgs for testing purposes.
> >> There are two drawbacks to the system :
>
> >> - it creates LOTS of symlinks (one per regular file). Not sure of the
> >> gravity of that one.
It is mostly ok, but I have had more than my fair share of experiences
with NFS+symlinks on Linux, so I am not looking forward there.
> >> - (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.
Sure, but with the proposal outlined above we could have our cake and
eat it, too.
> William
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
