I am not too familiar with how gentoo manages all of this, but it does sounds very similar to the spkg approach in sage:
1. Use original sources from the projects themselves 2. Maintain patches that are applied to that source 3. Use a shell script to build/install There are some significant differences though: 1. With spkg you can install anywhere (not just in system directories) - this is very important for people running on machines where they are not an admin. 2. With spkg it is trivial to have many versions install simultaneously. I find this very useful and I use this all the time. Do other sage folks? 3. spkg is designed to be run on stock Mac and Linux systems with very few dependencies. Currently the gentoo stuff is only really setup to work well on gentoo. People running ubuntu would much rather have .debs and people running FC would much rather have .rpms. While some of the gentoo stuff has been ported to Mac, most people don't have this installed. Making the spkg stuff work seamlessly on multipole platforms is extremely difficult (a nightmare in certain places) and is also really important. I would be very hesitant to move towards a solution (gentoo) that thus far has not been tested one bit. 4. portage is written in python. This assumes that python is installed. On most systems this is a good assumption, but not necessarily. I really like the fact that the spkg stuff is pure shell scripts and makefiles. For me, the bottom line is that the gentoo approach is interesting and similar to that of spkg, but the goals and details are different enough that I am not ready to base spkg on portage. I should say, though, that there are many ways that the spkg scripts could be improved. I have begun some of this work in my private copy, but there is a lot left to do. One of the reasons that I would very much like to get going with an hg repo for the spkg stuff is that I would like to begin sharing with work with others and proceed with refactoring keys parts of spkg that could be improved. On 6/1/07, Joel B. Mohler <[EMAIL PROTECTED]> wrote: > > 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/ -~----------~----~----~----~------~----~------~--~---
