On Sun, Nov 14, 2010 at 3:15 PM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > On 11/14/10 08:51 PM, William Stein wrote: >> >> On Sun, Nov 14, 2010 at 5:00 AM, Jeroen Demeyer<jdeme...@cage.ugent.be> >> wrote: >>> >>> Hello all, >>> >>> There is some work being done at #9418 at make GNU patch a standard >>> package such that, in the future, spkgs will be able to use "patch" >>> instead of "cp" to apply patches. >>> >>> It is a very simple solution which allows for: >>> * patching files depending on the system (e.g. if a patch needs to be >>> applied only on OS X systems) >>> * patching multiple files with one diff >>> * patching the same file with multiple diffs >>> * easily updating a spkg to a new upstream version >>> * easily adding a new patch to a spkg >>> * not being forced to update any spkgs, we can keep the old system if we >>> want (if there is a reason to do that for a particular spkg). >>> * low maintanance of the "patch" spkg: patch is a very stable program >>> with essentially no dependencies. >>> >>> I realize there have been other proposals to fix the patching, but in my >>> opinion simply using "patch" is the best solution. Let me also point >>> out that the spkg is already there (thanks to David Kirkby), so this is >>> not a theoretical discussion: >>> http://boxen.math.washington.edu/home/kirkby/patches/patch-2.6.1.spkg >>> I have also created a proof-of-concept spkg using "patch": >>> http://sage.math.washington.edu/home/jdemeyer/spkg/sphinx-1.0.4.p2.spkg >>> (there is a corresponding .p1 which uses "cp") >>> >>> So I would mainly like to know if somebody is truly against this >>> proposal (I would like to avoid posts of the form "but this other method >>> is even better than patch!" because that will get us nowhere). >> >> I'm now not against the proposal of using patch in spkg's, assuming >> patch gets shipped with Sage. I just don't want to personally have to >> do the work, and don't want patch to be a prerequisite to build sage. >> Given that there is a patch spkg, that's not an issue. > > The work is done > > http://boxen.math.washington.edu/home/kirkby/patches/patch-2.6.1.spkg > > The package is up for review > > http://trac.sagemath.org/sage_trac/ticket/9418 > > I've agreed to maintain it for a couple of years, which to be honest is not > a lot of work. There has been no updates at all in 2010, I somewhat doubt > the upstream source will update very often. Even if it does, I doubt the > benefits of updating patch will be as great as updating pari, gap, maxima or > endless other packages. But it's an easy package to update. It has its own > test suite. On my Xeon processor, I can build the package and run the test > suite in under 4 seconds. > > Jeroen has created an example sphinx package on that ticket: > > http://sage.math.washington.edu/home/jdemeyer/spkg/sphinx-1.0.4.p2.spkg > > But we need to decide on a set of instructions for people to use. For > example, if there are 3 files that need to be patched to work around a bug, > does one create 3 patches, or one patch which patches all three files? One > might chose to use a different approach if the files are very closely tied > together - like 'configure.ac' and 'configure'. Those issues need resolving.
For me the answer is very clear--a single issue gets a single patch file, whether or not it spans multiple files. If we need to fix an orthogonal issue, create a new patch that applies on top of the first, rather than creating conglomerate patch files simultaneously dealing with multiple issues. This was one of the big drawbacks with the copying method of doing things. > I think once we have a package which has shown to build on all systems, we > need to think carefully about how to be document creating and applying the > patches. > > I've got a ticket up for that, but that needs some discussion and can wait > until after we prove the package builds reliably on all systems. > >> >> I am still against storing patch files in the patches/ subdirectory in >> addition to the patched files. It's redundant and pointless. However, >> with patch included in Sage, then we can store *only* patches in the >> patches subdirectory, which makes lots of sense. >> >> - -William > > Like you, I can't see any point in storing both patch files and patched > versions of files. > > But the process from using 'cp' to patch will have to be a gradual one. > Create patch files when packages need to be upated. Agreed. We just shouldn't be using both in the same spkg. - Robert -- 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
