I should have invited myself to the conversation earlier I guess. I usually avoid those discussion because I could be seen as coming with a political agenda.
Technically I don't really care what sage does so long as it doesn't get in the way of what I am doing with regards to gentoo/prefix. Whether you go for easybuild (http://hpcugent.github.io/easybuild/) conda or another equivalent is fine by me. portage? I would be flattered and there are a number of things to deal with - which we can discuss further later. OS X support. Almost 3 years ago with Georg we tackled it and I had sage build in a 32bit prefix on 10.5.8 up to sage 5.9 I think. There are a number of prefix that degraded that state. At the time of the initial work with Georg we had successfully build ppc, x86 and x64 targets. Like I said there are trouble in prefix on OS X that make things difficult. It may be that the new (alternative) RAP prefix which build its own glibc could smooth all the problem. portage is fine in my opinion for sage. The number of package that I have installed and the number of customization of options (some of which are for sage-on-gentoo) mean that I sometimes have a very complicated dependency tree for portage to sort which make it look slow. pkgcore may be better. Relocation. Technically possible. In practise hard to achieve as it involves rewriting runpath inside binaries, this is highly OS dependent. The prefix solves Volker's LD_LIBRARY_PATH problem at the cost of relocation. Other gain dear to Volker: we can use any blas/lapack we want. Automated testing. I am not sure what Volker meant by that. In Gentoo you can set the feature "test" which will run the testsuite of the package before it is merged - provided that the ebuild allows it, the tests exist and it make sense. Currently we run the sage testsuite after sage is merged. Testing sage before merge would require a lot of work from our current point. François I guess I can claim "lead sage-on-gentoo developer" as a title. ________________________________________ From: sage-devel@googlegroups.com [sage-devel@googlegroups.com] on behalf of Michael Orlitzky [mich...@orlitzky.com] Sent: Monday, 13 January 2014 10:39 To: sage-devel@googlegroups.com Subject: Re: [sage-devel] Re: Python as build-time dependency On 01/12/2014 03:51 PM, R. Andrew Ohana wrote: > I'm a fan of gentoo's package manager specification (PMS) [1], however > the only package manager that is fully compliant is portage, which I > don't think is appropriate for sage. In particular: Keep in mind that the alternative is a bunch of hand-rolled python and bash scripts that punt on all of the hard problems that portage solves. > 1. It requires a noticeably bigger bootstrapping of the world. Lmonade > reduces this to only ~20 more packages than we already have (if I > recall), but imo this is still too many. Sage needs most of these too, they just aren't listed as dependencies anywhere. Things like binutils and glibc are assumed to exist. The fact that we don't build them explicitly in sage is a source of bugs. > 2. Portage itself has many dependencies, often with very explicit > version requirements. This makes non-Linux platforms a pain, since you > need things like gnu coreutils and findutils. Those two examples build and run fine on non-Linux platforms. Portage itself has very few dependencies, you can see them in its ebuild. There is the "implicit system" dependency that you get from prefix, but only one or two of those have version bounds, and it's all stuff that sage uses. > 3. It does not support tree relocation. What do you mean by this? > 4. (Lesser) The Portage source is atrocious, and it performs terribly. > > Imo, the most promising implementation of the PMS is paludis, however it > is not fully compliant (in particular prefix support is incomplete, and > binaries are assumed to be in the ELF format). > > [1] http://wiki.gentoo.org/wiki/Project:PMS If for the sake of argument we rule out portage, I would concentrate on pkgcore instead. It's missing EAPI5 support at the moment, but there's some discussion in Gentoo about whether to switch the focus from portage to pkgcore in the long term. Otherwise it's fast, clean, written in python, and the spiritual successor to portage. But portage is fine. It's running tens of thousands of Gentoo machines, and somebody else writes it for you, which is where we stand to benefit the most. Dependency resolution is the slow part, and users would rarely need to emerge anything. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out. This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
