On Sat, Jul 3, 2010 at 6:27 AM, Volker Braun <vbraun.n...@gmail.com> wrote: > I would propose a mercurial patch queue in the spgk root directory. > Then sage -pkg simply checks that either all patches in the queue are > applied or that there exists an old-style /patches directory and no > queue.
Since we all seem to like mercurial queues, we could also consider using quilt (which could be thought of as "mercurial queues without mercurial"). (Actually, I'm pretty sure that quilt came first, and then mq based its command-line interface on quilt.) Debian, who has the same sort of issue with upgrading packages that we do (times several hundred!), uses quilt for many of their packages, and recommends quilt in the "New Maintainers' Guide". The revision-control portion of the workflow for updating a package in the easiest case would go something like this: 1) extract spkg 2) rename directory to new version 3) remove old src/, unpack new source into src/ 4) type: "quilt push -a"; make sure that all patches apply 5) type: "quilt pop -a" 6) edit SPKG.txt, check in changes to top-level repository 7) sage -pkg The spkg-install would include: "quilt push -a" If there's an error in step 4 (some old patch doesn't apply correctly to the new source), then the procedure for fixing it is the same as with queues: push patches one at a time with "quilt push"; when you get to the patch that fails to apply, hand-apply it and do "quilt refresh". For cases where we have multiple variants, quilt supports multiple series files; instead of "quilt push -a", it would be "QUILT_SERIES=series.sun4v quilt push -a". In the above variant of the proposal, we would need to include quilt as an spkg. The source is a 420 kilobyte .tar.gz. On my desktop, it takes 3.5 seconds to build (2 seconds to run configure, 1.5 seconds to run make). We could avoid shipping quilt as a standard spkg by rewriting "quilt push -a" as our own shell script. (This is quite simple, and actually recommended by the documentation. All the shell script needs to do is take the series file and remove comments; then all that's left is a list of patches to apply, one patch filename per line.) Then only developers who want to work on spkgs including patches would need quilt, so it could be an optional spkg (or we could require such developers to just install quilt themselves). We could avoid shipping either patch or quilt by going back to William's suggestion at the top of the thread, where we automatically make copies of the patched files at "sage -pkg" time, so that we can copy the files at spkg build time without needing patch. With the extra structure provided by quilt, with every variant represented by a series.FOO file, I believe this would be straightforward even in the case of multiple variants (although the multiple copies of patched files would certainly make the spkg bigger). I feel strongly (but have no hard evidence, of course) that the problem of package updating with quilt would be much, much easier than our current system, and also much easier than a system using patch files in the case where the patches don't apply cleanly and a "quilt refresh" is needed. I'd be willing to put some effort into switching to quilt as the recommended way to deal with patches in Sage, up to and including: * make an spkg for quilt * convert one spkg to using quilt, try to upgrade it with the above workflow, and report on the process * if people like the third variant, where we don't ship patch and instead we automatically generate the patched versions of files at spkg-build time, I'd be willing to write that tool Carl -- 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
