On 03/02/2012 04:45 PM, Georg S. Weber wrote:
I don't agree for OS X. I myself built Gentoo Prefix on several OS X
versions, Sage-on-Gentoo on top of it, as well as lmonade, and my
impression is that Sage is a good deal better supported on OS X; and I
even daresay that currently there are more developers caring actively
for Sage on OS X, than there are developers caring actively for Gentoo
Prefix on OS X. And this does matter.
I don't know the state on Solaris (neither really for Sage, nor for
Gentoo Prefix), but the state of Gentoo Prefix (on Cygwin and) on
native Windows was my very first motivation to have a close look at
Gentoo Prefix.
The question isn't who's better /now/. Certainly, a large amount of
effort goes into making Sage portable (much more than does Prefix). I
just think that if all of that Sage effort were spent on Prefix, it
would go further.
It does solve all of the problems I've thought of, but I probably haven't
thought of them all. If it would be useful to create a list ...
Gentoo Prefix has a list of its own problems (read: lacking features),
that the Sage project already did solve. To name a few (I hope all the
important ones):
1. Any Sage installation is relocatable. Gentoo Prefix isn't, and
although some work has been done now and then in that direction, it's
nothing the Gentoo Prefix "upstream" is much interested in. Even
assuming that this might work at a certain point of time in the
future, I doubt that Gentoo Prefix upstream would be interested in
maintaining this feature, i.e. testing for regressions in that
direction. (OTOH, from the Sage development point of view, all
components of Sage are already known to be relocatable, so this keeps
at worst the maintaining work needed at level, but does not increase
it.)
When you say relocatable, do you mean the entire directory? For example,
mv ~/src/sage-5.0.beta5 ~/src/sage-old
? I'm not sure how prefix handles that, but I can check. I'm sure we
could make /sage/ work, but the rest of the prefix system might be trickier.
(Why would you want to do that?)
2. Sage can be installed in two (!) incredibly easy ways, as source
distribution (like Gentoo Prefix et. al.), but also as a binary
distribution. The latter way is more or less blocked for Gentoo Prefix
and descendants, as long as they're not relocatable (one just cannot
locate the exact root directory "beforehand" in important use cases)
---see the first point.
Why would the binaries work any different than they do now?
3. And honestly, bootstrapping Gentoo Prefix is for experts, not for
the bulk of users that the Sage project addresses. The lmonade project
made some break-through progresses in the right direction (e.g. in not
necessarily needing to bootstrap an entire C/C++ compiler, as is
mandatory for Gentoo Prefix due to the way the latter avoids the *nix
equivalent of the "dll hell"), but currently the lmonade project still
falls short of the mark of providing a both easy and robust (!) way of
installing it on a greater variety of systems.
Agreed, we would have to make this easy.
4. Ease of development by cloning the sage tree, as mentioned already
by Francois. I dimly remember that in those git (gerrit?) threads
William said something about that the current sage way certainly isn't
set in stone. But one either would have to devise a way to easily
clone *an entire Gentoo Prefix (or lmonade)*, or to easily install
several concurrent Sage library versions into one and the same Gentoo
Prefix, and to switch between them. To achieve the latter, there do
exist ready-to-go mechanims in Gentoo (more than one, think e.g. of
the automake/autoconf wrappers, or the way one can switch between
different Python versions), but to my knowledge, till now no one has
come up with some proof-of-concept in that direction for Sage(-on-
Gentoo).
I think Francois was referring to how easy it is to hack on the
dependencies. Right now, you just extract the spkg, modify it, tar it
up, and sage -f it.
In prefix, you would revbump (-r1) your ebuild, stick a patch in the
'files' directory, edit the ebuild to use the patch, and then re-emerge
that package. If you don't like patches, you could also just set SRC_URI
to e.g. file:///my-modified-package.tar.bz2 and re-emerge.
Not much harder, and it isn't sage-specific. Thousands of Gentoo users
now know how to hack on sage!
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
