There's something I've been thinking about for awhile about the spkg packages. It seems relevant to the discussion at hand, but overall I'm not sure that there is any immediate merit to my comments. I'm a (happy) gentoo user and one of the principle reasons I'm with gentoo is the package management -- their portage system. Of course, it's a build-from-source model and it's really remarkably similar to how the spkg scripts do things. Both spkg and gentoo are also similar to the bsd ports method of doing things.
The analog of the spkg spkg-install install script is the ebuild in gentoo. Here's an ebuild for PARI from the online CVS: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-mathematics/pari/pari-2.1.5-r4.ebuild?rev=1.5&view=markup Some things to note: - in the src_unpack, gentoo applies some patches which are kept on gentoo servers - it's essentially a bash script, but I believe there are some frills added somehow The main relation of this to the current discussion is that gentoo solves the patch/mainline problem by distributing patch files which are applied on the user's computer before the build of the package in question. Sometimes there are a large number of patches applied (I don't have a specific example, but I'm pretty sure I've seen as many as 10-15 patches applied before a build.) This way it is very clear to any concerned individual exactly what is coming from upstream (the original package is downloaded as part of the install process), vs. what is coming from the gentoo packagers. In gentoo, when a new package comes out, the upgrade process can be as simple as updating the filename of the ebuild file to have the new version number. If you are applying patches, things are a bit more complicated because you have to check if the patches are still needed or applicable. However, I'm sure there are many times when the patches just carry forward with-out a hitch. A good goal would be to keep those patches headed upstream so that new versions could eliminate all the patches of the old -- but that's easier said than done. Now, here's a wilder idea which I don't think is totally undoable. It seems to me that it might be possible to detatch the portage system scripts from a gentoo system and rewrite all the spkg-install scripts as ebuilds. This has two benefits: 1) You don't have to work on spkg (and reinventing the from-source package management wheel) 2) Once those ebuilds are done, you have sage packaged for gentoo. There should be absolutely nothing left to do. Instead of installing under the $SAGE_HOME directory, you install things to the root of the tree (portage has the ability to install things to a subdirectory -- of course, the norm is to install stuff to the root of the tree and I've never had a reason to do otherwise.) In portage parlance, you could say that you have a SAGE overlay which has a bunch of mathematical packages. Actually, after a bit of searching in the gentoo forums, I came accross this: http://www.pkgcore.org/ It appears to be an attempt at non-gentoo-ifying portage, but the website is sort of useless for actually learning about the project. And, for the snake lovers, portage is written in python :) ! -- Joel On Thursday 31 May 2007 22:42, Brian Granger wrote: > This looks very interesting, I hadn't seen this before. I need to > learn more about hg for sure. Would this approach require having the > source to the upstream project in an hg repo? > > On 5/31/07, Fernando Perez <[EMAIL PROTECTED]> wrote: > > On 5/31/07, Brian Granger <[EMAIL PROTECTED]> wrote: > > > source. This doesn't answer the question of how to maintain those > > > patches, that don't get sent back upstream. This definitely needs to > > > be addressed. > > > > If I understand correctly, that's what mercurial queues are for: > > > > http://hgbook.red-bean.com/hgbookch12.html > > > > Cheers, > > > > f > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
