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.
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.
Dave
--
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
