On Thu, 23 Apr 2009, mabshoff wrote:
> Another thing: In 3.4.1 we downgraded GAP to 4.4.10 from 4.4.12 that
> was upgraded in Sage 3.3 due to a significant number of bugs and
> issues in GAP 4.4.12. How would you deal with something like that in
> the packaged version of Sage? The whole point about shipping nearly
> every dependency in Sage was that we can do things like that because
> it is the only way Sage does work reliably and pass doctests. That
> does not really work too well with a distribution like Debain with
> tens of thousands of packages. While the number of packages depending
> on GAP are probably close to zero in Debian for something like NTL
> this might be an issue.
Actually, NTL wasn't in Debian until I packaged it as part of my effort to
get Sage into Debian. So at present all its dependencies are maintained
by me. But I understand your point -- GMP, for example, has dozens of
dependencies. Upgrades of popular libraries in distributions like Debian
are often done with a great deal of staging and care so that problems are
discovered before people upgrade in the first place.
As for the actual issue of downgrading packages, that can be difficult in
a distribution. I have seen it done in Debian in cases where the new
release is totally broken -- this is usually done by Debian releasing a
version 4.4.12+really4.4.10 or similar. But perhaps instead the Debian
maintainer will work with upstream to fix the bugs in the newer release.
It's important to understand that distribution release cycles have
relatively long freeze periods during which one only fixes bugs, which
means one generally has quite a bit of warning when there is a problem
that results in a doctest failure, and so one can explore a number of
measures for trying to fix the issue before a release goes out.
> Another problem is that often we have to put in fixes or use CVS for
> non-Linux builds and with the Windows port this will become even more
> extreme. So I truly don't see any reasonable hope we will ship clean
> upstream anytime soon. Obviously if it is clean upstream and fixes in
> patches in the spkg you can just ignore it.
Fixes for non-Linux platforms like Solaris or Windows that don't change
ABI should be fine in a stable release. There are a lot of Sage patches
that add
#ifdef CYGWIN
...
#endif
or similar that can be safely assumed on inspection to be harmless on
Linux. If Sage only is applying patches like this, it is easy to just use
the upstream release Sage is patching. That's why I stated the goal of
cleaning out all ABI-changing patches, not cleaning out all patches
altogether.
-Tim Abbott
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
