On Tue, 21 Feb 2012 00:56:13 +0800 Keshav Kini <keshav.k...@gmail.com> wrote:
> Burcin Erocal <bur...@erocal.org> writes: <snip> > >> Just to be clear, sage-on-gentoo itself has no goal of being a way > >> to distribute Sage in general. It is simply a port of Sage and its > >> SPKGs to the Gentoo package management system, using the "overlay" > >> architecture the Gentoo distro has (similar to Personal Package > >> Archives on Ubuntu, if you're familiar with those). Basically you > >> just put something in a config file on your Gentoo system which > >> says "augment the package repository with ebuilds from > >> sage-on-gentoo", and you can now install Sage system-wide. > >> > >> It is Burcin's lmonade project which combines sage-on-gentoo with > >> Gentoo Prefix, which is a portable version of the Gentoo package > >> management system which can be run in a folder on any system, and > >> more importantly, can be customized to supply any set of packages, > >> not necessarily the entire set of officially sanctioned packages > >> that comprise the Gentoo Linux distribution. As the name suggests, > >> it's similar to how you might use `./configure --prefix=/some/dir` > >> in order to install a program to /some/dir/bin rather > >> than /usr/bin, say. > > > > Thanks Keshav, that's a great summary of the relation between > > gentoo-prefix, sage-on-gentoo and lmonade [1]. For the record, I'd > > be very happy to see Sage use lmonade for the distribution aspects. > > > > [1] http://www.lmona.de/ > > > > lmonade was born because I thought that a customized Sage > > distribution like William's psage [2] was not maintainable in the > > long term. It still needs some work to cover all functionality of > > the Sage distribution, such as relocation and support for > > development of Sage. Given time, these are not hard problems. > > Unfortunately, I haven't had much time to work on lmonade lately. > > > > [2] http://purple.sagemath.org/ > > Hmm, so basically you wanted psage to just be sage with certain USE > flags turned off? Essentially, yes. psage (like Sage) is a separate python library as well as a distribution. psage the python library would have its ebuild, which depends on Sage. The Sage ebuild would have USE flags to choose if you want fortran or maxima installed. <snip> > >> Here is a highly abbreviated directory tree of lmonade, as it > >> appears in the installation I made the other day, for reference: > >> > >> lmonade/ > >> | dist package management / build system > >> | | distfiles/ downloaded upstream source tarballs > >> | | log/ build logs > >> | ` portage/ ebuilds, patches, etc. > >> | ` sci-mathematics/ > >> | ` gap/ > >> | | files/ > >> | | | gap-4.4.12-sage-and-steve-lintons-itanium.patch > >> | | ` gap-4.4.12-sage-strict_aliasing.patch > >> | | gap-4.4.12-r2.ebuild > >> | ` metadata.xml > >> ` local/ software is installed here > >> | bin/, etc/, include/, lib/, libexec/, sbin/ > >> ` share/ > >> ` sage/ > >> ` devel/ corresponds to $SAGE_ROOT/devel today > >> > >> So the "package repository" would be dist/portage, and the "sage > >> library repository" would be kept at > >> local/share/sage/devel/sage-main (or hopefully just ...devel/sage, > >> once we get rid of `sage -clone`). I don't actually know my way > >> around this directory structure very well, but those are the main > >> takeaways, I think. > > > > Your description is accurate. The development repositories will be > > in devel/. pynac and pypolymake live ebuilds already put their > > files in this location. The separation of the sage ebuilds stopped > > me from using the same scheme for sage up to now. The goal is to > > put the development repository for a package foo in devel/foo once > > the user runs > > > > lmnd devel foo > > > > Well, by ...devel/sage I meant local/share/sage/devel/sage , as > opposed to local/share/sage/devel/sage-main . Are you saying that you > would put development repositories in a top level directory, > lmonade/devel ? Yep. Top level directory named devel/, like it is in Sage, but only specific to the Sage library and notebook. > I don't see a live ebuild for pynac nor any ebuild for pypolymake, > btw... I think I have the latest lmonade version > (prefix-20111201.tar.bz2, right?). The files with version number 9999 are live ebuilds. They pull from the mercurial repositories and build the latest version of the code: https://bitbucket.org/burcin/lmnd-prefix/src/tip/sci-libs/pynac https://bitbucket.org/burcin/lmnd-prefix/src/tip/sci-mathematics/pypolymake Try this (from your lmonade root, in the prefix shell): cd local/etc/portage echo sci-libs/pynac devel.env > package.env echo =sci-libs/pynac-9999 ** > package.accept_keywords emerge pynac Then check <lmnd root>/devel/. If the above doesn't work, you probably don't have local/etc/portage/env/devel.env yet. Previous installers didn't install that file. :) https://bitbucket.org/burcin/lmnd-prefix/raw/6f22d7022a14/scripts/devel.env You will probably have to update your package repository. It is best to symlink dist/portage to a clone of the bitbucket repo. See here for more info: http://wiki.lmona.de/devel/workflow > >> You can see the contents of gap-4.4.12-r2.ebuild here: > >> https://github.com/cschwan/sage-on-gentoo/blob/83deaae5/sci-mathematics/gap/gap-4.4.12-r2.ebuild > >> > >> There are some seeming oddities there, like the USE flag "emacs" > >> which pulls in Emacs as a dependency and then installs the Emacs > >> mode for GAP into it - clearly not something we want to do, and > >> indeed it's not enabled by default in lmonade. It's there because, > >> as I said, sage-on-gentoo is meant to allow you to install Sage > >> into a full Gentoo system, where it *would* make sense to do that. > >> > >> I guess to avoid extra maintenance load we'll just have to leave > >> that extra stuff in, both in sage-on-gentoo and on our own > >> packaging repo. (And who knows, maybe someone *does* want a local > >> copy of Emacs or whateverinside their Sage installation...) I > >> doubt we'll be able to actually use sage-on-gentoo directly as our > >> packaging repo, but at least we can keep them similar (?). > > Can you comment on this, please? As you also point out, to reduce the packaging burden, it is best to keep as close to upstream as possible. This may not be a problem for Sage, since there are already so many people working on packaging, but it is a real issue for lmonade. The package manager is very flexible, so using the ebuilds from gentoo or sage-on-gentoo is easy. You just turn off the USE flags corresponding to the features you don't want by default. Again, as you wrote above, sage-on-gentoo only contains the ebuilds that are not provided by gentoo itself. Sage needs everything to work in a prefix environment, which requires quite a bit more than sage-on-gentoo. Here Gentoo-prefix comes to the rescue, but that assumes you want to build the whole distribution in a prefix, including the toolchain for instance. lmonade uses the toolchain installed on the host. Hopefully in the future, it will be able to detect which dependencies are installed on the host and avoid rebuilding them. > >> By the way, it looks like only three packages in sage-on-gentoo > >> actually have a "sage" USE flag defined (PolyBoRi, Python, and > >> LinBox). It seems that the others, including GAP, just install > >> Sage's patches whether you want them or not. I'm not sure why this > >> is - maybe it's just because it's painful to specially create a > >> "sage" USE flag for every package, or maybe it's because > >> sage-on-gentoo wants to get Sage's patches included in Gentoo > >> proper as default patches, or maybe there's some other reason. > > > > AFAIR, the only patch contained in the GAP spkg was a fix for > > itanium from Steve Linton. This is useful in general. No need to > > hide it behind a use flag. > > Well, right, but surely there are more than three SPKGs which have > Sage-specific fixes that others don't care about? Well, maybe not, I > don't know :) I don't think there are so many. In most cases the "Sage specific" fix is actually a bug fix. These should be widely available anyway. 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. 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
