> > 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?
For Python packages using setuptools, setup.py has an option --
root=... just for that. Essentially, anything that is packaged for a
linux distribution is packaged this way, you install it with a fake
root, create a tarball of that and call it a (deb|rpm) package, so all
build systems that I know of implement something similar.
And as you say, those that don't are easily fixable.
> 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.
I am thinking of something like a wrapper (sage_graft ?) that would do
the clever thing in unix, and plainly move the files in windows. So no
functionality is lost in windows, and some is gained in unix ...
To answer William's question : the main problem with deb/rpm is that
you need to keep a central database of installed files, whereas a tree
of links contains the information within itself, which is simpler (I
don't really feel like implementing something like that just for the
sake of it, and adapting say APT would be tedious). Plus, they don't
allow for the "swappability" of different versions by changing
symlinks (if you exclude /etc/alternatives). On the other hand, now
that I think of it, maintaining such a database would probably be more
cross-platform. The whole dependency tracking business is probably
more trouble than it's worth in the context of Sage though - unless it
significantly simplifies distribution / patching / installation /
updates, like e.g. Fink doe on Mac OS X. But given that Sage is a
controlled environment with few packages, it's certainly overkill.
I will play around with the idea and see what works out, and I am
willing to try and provide a full working solution with two or three
modified packages as proof of concept. In any case, if some system is
implemented, each one of the packages will need to be tweaked to use
it - but that need not be done all at once.
/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
-~----------~----~----~----~------~----~------~--~---
