Nick Alexander wrote:
As much as I can see why people do not like this, I can see a lot of
logic in William's approach.
To add to what David said, some of this is historical. The 100 packages
sage builds now are unwieldy, but it was not always so. Earlier
distributions contained much less, and shipping them all seemed like a
reasonable trade for "build anywhere". It's worked surprisingly well,
and we are attached to it now.
A thought occurs -- perhaps we could have sage .spkg packages that in
fact are just dummies that really use the system libraries. That might
provide a transition path to mixed .spkg/system libraries.
Nick
One obvious advantage of shipping all the code is that you know more precisely
what the person is using.
I believe the thread below indicates one of issues. (Read the full thread if you
wish, but here is a summary).
1) Alex Ghitza builds an Arch Linux binary using gcc 4.4.2 and puts it on the
Sage web site. It works for Alex
2) Akbar Hidaya downloads that binary and finds it does not work for him.
3) The binary stops working for Alex Ghitza once he updates his gcc from 4.4.2
to 4.4.3.
4) Alex correctly guess that the user has updated his gcc.
http://groups.google.com/group/sage-support/browse_thread/thread/aba48495d9c09e03
I think this is an rare example, but it shows how just updating gcc can cause a
failure. I'm sure having a version of gcc too old will also cause problems,
which is why I suggested including the gcc libraries.
Now consider what happens when the end user can have loads of different
libraries at different versions. Debugging problems would become much more
problematic.
Simply insisting that the user upgrade their libraries will not be practical if
the user does not have root access.
Many system admins will be unwilling to update system libraries for users. They
simply can't take the risk the updated libraries will not cause problems for
other uses.
In an ideal world, updated libraries would be backwards compatible and introduce
no new bugs. In practice, neither are always true.
I'm also unaware of any way of determining library versions in general.
Dave
--
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
