On Mar 2, 2012 1:04 AM, "Robert Bradshaw" <rober...@math.washington.edu> wrote: . > > I think the vast majority of spkgs should be vanilla upstream, and for > those that we do patch, they're likely bugfixes that should make their > way upstream. But that leaves several packages that we still need to > patch (either sage-specific changes, or because the > upstream-patch-release process is too slow). We can't simply not > support this.
Moreover, "upstream" includes a huge number of versions of Linux distributions, versions of OS X, Solaris, etc. It is only by caring about actual users (who usually don't have root) that one can begin to comprehend the problem a monolithic distribution of Sage solves. > > Note that the "Sage specific" fix for Python was merged upstream, so it > > will be in a later release. LinBox is fixing their commentator, so we > > shouldn't need to patch that away either. > > > > I introduced the patch that replaces PolyBoRi's python library to use > > Sage instead of their Boost wrappers. That was a bad idea. These days > > we are trying to come up with a way to remove that. Otherwise you cannot use that installation of PolyBoRi without Sage. > > > > > > The fact that Sage can freely patch the components it relies on > > certainly lets Sage developers work freely and speeds up Sage > > development. But it also reduces the need to push fixes upstream. > > > > <snip> > >> >> > But yes, this sounds like a great idea! So the > >> >> > collection of .ebuild files (and their supporting patches, etc.) > >> >> > is in the Sage repository, but periodically exported somewhere > >> >> > central (owned by us? Gentoo?) that people pull from, right? > >> >> > >> >> Er, nope. The ebuild corresponding to the Sage library itself > >> >> would be stored in the Sage repository, and periodically (upon the > >> >> release of a new Sage version) be exported into our package > >> >> repository. All other ebuilds and patches would be put directly > >> >> into that package repository, which would be hosted live > >> >> somewhere, say on github. Our package repository would look very > >> >> similar to the current sage-on-gentoo repository, i.e. be a > >> >> portage tree providing ebuilds. The other repository would be the > >> >> Sage repository. > >> >> > >> >> In other words, we would consider the Sage library as another > >> >> "upstream package", except that it's aware of its part to play in > >> >> the Sage package repository, and thus provides its own ebuild as > >> >> part of the distributed source code each time it distributes a new > >> >> version (i.e when we release a new version), whereas for other > >> >> packages we would have to write our own ebuilds for them (or > >> >> borrow them from Gentoo), not constantly, but whenever the > >> >> upstream developers released a new version. > >> > > >> > I don't see the need to keep the Sage ebuild in the repository > >> > containing the Sage library. It should also be in the package > >> > repository. Just like: > >> > > >> > https://bitbucket.org/burcin/lmnd-prefix/src/tip/sci-mathematics/sage/ > >> > > >> > (I really need to update. Actually, I was just working on using git > >> > to automate synchronizing with gentoo-x86, gentoo-prefix, > >> > gentoo-science and sage-on-gentoo.) > >> > >> Well, I was suggesting this because Robert was saying that if you > >> rewind your Sage library repo to an older state where you need older > >> external packages installed, `sage -b` should downgrade those > >> packages too, which seems like a great idea to me. > > > > I don't see why the Sage library is so special that it needs to store > > information about how to build its dependencies itself. There are > > several software packages that depend on specific versions of certain > > libraries. Here is the list with the dependencies of firefox on gentoo: > > > > $ qdepends www-client/firefox > > www-client/firefox-10.0.1: >=sys-devel/binutils-2.16.1 >=dev-libs/nss-3.13.1 >=dev-libs/nspr-4.8.8 >=dev-libs/glib-2.26:2 >=media-libs/mesa-7.10 media-libs/libpng[apng] virtual/libffi >=media-libs/libvpx-0.9.7 media-libs/alsa-lib net-misc/curl dev-util/pkgconfig >=dev-lang/yasm-1.1 >=sys-apps/sed-4 >=app-admin/eselect-python-20091230 x11-libs/libXrender x11-libs/libXt x11-libs/libXmu >=sys-libs/zlib-1.1.4 dev-util/pkgconfig =dev-lang/python-2*[threads] app-arch/zip app-arch/unzip >=app-text/hunspell-1.2 dev-libs/expat >=dev-libs/libIDL-0.8.0 >=dev-libs/libevent-1.4.7 >=x11-libs/cairo-1.8[X] >=x11-libs/gtk+-2.8.6:2 >=x11-libs/pango-1.10.1[X] virtual/jpeg virtual/freedesktop-icon-theme media-libs/alsa-lib >=dev-libs/dbus-glib-0.72 >=x11-libs/libnotify-0.4 >=x11-libs/startup-notification-0.8 net-wireless/wireless-tools =sys-devel/automake-1.11* =sys-devel/autoconf-2.1* sys-devel/libtool app-arch/unzip > > > > There are 40 items in that list. I assume that is similar to the requirements of the Sage library. Like firefox, the Sage library can use one of the many well established methods to check if the required libraries are installed on the system. > > Makes sense to me for stuff like atlas, libgzip, and libpng, but for > some (e.g. Python) we modify the install itself (it's site-packages, > though perhaps this is not necessary), and I'd like multiple Sage's to > be installed in parallel and completely not interfering with the > system). > > - 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 -- 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
