On Sat, 5 Nov 2011 17:23:38 -0700 (PDT) leif <not.rea...@online.de> wrote:
> On 5 Nov., 21:24, "Justin C. Walker" <jus...@mac.com> wrote: > > On Nov 5, 2011, at 12:16 , Julien Puydt wrote: > > > > > Le 05/11/2011 17:42, William Stein a écrit : > > >> What do you base this "probably" on? Having started and watched > > >> Sage "evolve" of over 6 years, if anything it is not evolving in > > >> the direction you suggest. > > > > > Fair point. But that can't last. > > > > Trying to make a "self-contained" system that utilizes a wide > > variety of system-provided libraries is an exercise leading to > > premature grey hair and high blood pressure. > > > > There are so many different versions of each library and system > > (for Linux, in particular) that it's a practical impossibility to > > produce a package like Sage that will work on the systems currently > > supported. > > > Well, one could check much more in Sage's 'configure', and eventually > instruct the user to install (or update) some system packages and/or > download additional spkgs, probably specific to the system (e.g. MacOS > X, Cygwin, Solaris). > > We could keep the bloated "[almost] everything included" "source" > tarball, but could also offer a stripped-down one which doesn't carry > all that unnecessary baggage (like Cephes, iconv, termcap, readline, > gfortran binaries(!), patch, Mercurial, ...). > > Projects like Sage-on-Gentoo show that it's possible to use much more > system packages / libraries than we do, and shipping all *by* > *default* (without any option to omit some packages), some just doing > > if [ "$UNAME" = foo ]; then > # no need to build it on 'foo' > exit 0 > fi > > or building vanilla upstream without any Sage-specific configuration > (except --prefix=...) is certainly suboptimal, although probably > easier to maintain (modulo issues *we* have to deal with that would > otherwise get reported upstream, either package or OS / distribution). > > As discussed elsewhere, a first step would be to split off the Sage- > specific parts of spkgs from the upstream tarball / source tree. We'd > also need better dependencies, with version number matching, a > distinction between build and runtime requirements, etc. pp., i.e. > modular, formal package metadata (which could include our current > build scripts, although they'd also better be split into pieces, with > a lot factored out). Most of this has already been done by the sage-on-gentoo project. Using gentoo-prefix, it is even possible to install it on different operating systems. I've been working on making a sage like distribution by merging these two. The repository is here: https://bitbucket.org/burcin/sage-prefix Instructions on the bitbucket wiki are probably old. Latest tarball is here: http://www.lmona.de/files/prefix-20111027.tar.bz2 With this framework, it would be simple to split the profiles for different linux distributions and customize the package.provided file to install only a subset of the dependencies. Cheers, Burcin -- 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
