On Feb 23, 2010, at 9:53 PM, Robert Bradshaw wrote:
On Feb 23, 2010, at 1:44 PM, Kasper Peeters wrote:
It would be better for end users if we built standard rpm/deb/etc.
packages that integrate well with the rest of each Linux, OS X,
Solaris, Windows, etc., operating system, and of course regularly
tested that the full test suite passes on each system, and when
packages on those systems get old or too new, deal with those
problems. That would be wonderful. Unfortunately, we have to be
realistic, given the resources that we have available.
The problem is that, by relying on your own versions of many tools
and libraries, you essentially prevent other people from helping
you with packaging for those rpm/deb/etc. systems. Because those
other people are now burdened with the task of separating those
libraries and patching things on the Sage side. Which is harder for
them, because they do not know what to watch out for. As a result,
you are
burdened with more work, because now _you_ have to take care of
making
Sage installation/compilation easy, instead of having distribution
packagers take care of that.
We would have to take care of making Sage installation/compilation
easy anyways, as many of the packages we rely on (often the most
fragile ones) are rather specialized math programs that aren't
always in all the standard distributions, and it would fall on us to
do all the work to get them into all the packaging systems. And we
would probably have to roll our own for Solaris, OS X, or any other
platform that doesn't yet have a large packaging distribution
infrastructure. It would also make Sage releases much more dependent
on outside people and projects--right now if one finds a bug in an
upstream package one can get it into the next sage release rather
than wait for upstream to accept and push it. Also if there were one
package repository/system that all supported platforms used, things
would be much simpler.
I have some personal experience with Cython. I'm very greatful for
whoever makes .dep and .rpm packages of Cython, but I do have to
admit that they're not always up to date and I'm glad I can get the
new Cython into Sage before waiting for every packaging system we
would rely on to finally upgrade to the latest.
The consequence is clearly visible: there are no up-to-date packages
of Sage for any of the Linux distributions.
I'm playing devils advocate here a bit, but there are up-to-date
binaries of Sage for many Linux distributions, so it would seem
that's (for the moment) a more effective way to go. Note that if
they accepted monolithic packages this would be much easier.
Which means that for many
users, installing Sage is actually _harder_ than installing most
other
software.
That is sad but true.
But don't get me wrong: I am definitely not saying that it is easy to
make Sage deal with distribution-supplied libraries, and I fully
understand the historical reasons for shipping Sage with such a large
number of spkg's.
What I am saying is that, in the long run, it is much better to steer
clear of that.
And therefore, that it would be unwise to add more of your own
versions
of libraries, _especially_ when it concerns libraries which every
distribution
already ships with (like gcc-lib). I can see that Macports is having
problems
with the 'we ship everything ourselves' logic, and I don't see how
Sage is
going to avoid that.
Despite my defense of the way things are, I am very excited about
the recent push for the Gentoo port, and I'm curious to see how it
will be maintaining it over, say, the next year. We will see if, for
example, library versioning issues are a major headache or non-
issue. Perhaps eventually this will even become the default way of
building/distributing Sage for Linux. I'm not sure how we would move
away from the monolithic source and binary model for other platforms
though, especially given our mission of being a viable alternative
to the commercial offerings.
[pressed send too soon]
Another thing I really like about the monolithic approach is that it
makes it really easy to install Sage as non-root, as many times as you
want, and to move and delete them. Of course some users could care
less about this.
- Robert
--
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
