Robert, the advantage is that it will simplify the *development* of Sage. Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with "specific versions" of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... IMHO... Dmitrii On Jan 22, 4:05 am, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote: > > > On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy <peterjer...@acm.org> > > wrote: > >> My personal feeling is that it would be nice if some of the more > >> generic > >> packages (eg bzip, zlib, readline, mercurial) were moved out of sage > >> and made explicit requirements. > > > +1 > > > I think Sage is mature enough now to slowly migrate toward this. > > Besides, there can still be spkgs for those packages, and there could > > be a sage-with-batteries-included tarball with dependencies included. > > What would be the advantage? The easier it is for users to go from a > standard distro/OS X box to a running Sage the better. Also, there's > the much more important Windows port to consider. > > One of the reasons we ship our own of so much stuff is that we require > specific versions (e.g. you can't just drop in a new version of pari, > maxima, or gap, and have it Just Work). Is that an issue for any of > the above packages? Also, we require the dev versions of the above > packages, not just binaries (which is what many systems come with). > > - 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
