On Thu, Jul 1, 2010 at 11:21 AM, David Kirkby <david.kir...@onetel.net> wrote: > On 1 July 2010 18:02, William Stein <wst...@gmail.com> wrote: > >> I vote NO to including patch in sage. >> >> 1. We can accomplish the same thing when creating the spkg. E.g, the command >> >> sage -pkg foo-1.2.3 >> >> could *automatically* apply patch using each file in >> foo-1.2.3/patches/ and create the corresponding patched files. To >> *creators* of spkg's this is functionally equivalent to what is >> proposed, and perhaps even better, because use of patch files will be >> carefully organized, instead of being done by adhoc use of the patch >> command in spkg-install. > > I was not suggesting it to be used by the creators of packages - they > need a 'diff' command, not a patch command.
Patch would be used explicitly by developers in writing the spkg-installs. > >> Also, no current spkg-install's have to be >> changed at all. > > No, but you know as well as I do, that this is an ongoing process. I > don't know how many files in Sage get patched, but it is a lot of > them. My suggestion requires changing no spkg-install files; your involves changing all of them. Mine does involve rewriting patches/ directories though. >> By apply patch at runtime, we only assume the user >> has the ability to patch files, and since Mercurial is in Sage this >> adds no dependencies. > > In order to have Mercurial you need Python, which is currently patched > multiple times. Python is certainly one of the packages that has a > great many patches. The Python that comes with Solaris is too old to > build Mercurial to to use Mercurial one would need to In my proposal patch is *only* used when typing sage -pkg foo-1.2.3 At that point, one likely has Mercurial/Python, etc., installed and working. >> 2. We should never, ever add any new packages to sage without being >> very, very careful first. Every package added to sage increases later >> porting work, maintenance work, etc. forever. This is particularly a >> concern to *me*, since some of you come and go, but I'll be dealing >> with sage pretty much forever. >> >> -- William > > I would have expected the maintenance on 'patch' to be very low > indeed. It has no dependencies other than a C compiler and 'make'. > There are no optional things you can enable with options to the > configure script. > > Take a look if you want > > http://boxen.math.washington.edu/home/kirkby/patches/patch-2.6.1.spkg > > I wont create a ticket for it, since you are obviously not keen, but I > thought I'd post a link given I'd made the package anyway. > > On my Ultra 27, tt takes a grand total of 3.2 seconds to install it. > > real 0m3.191s > user 0m2.698s > sys 0m1.640s > Successfully installed patch-2.6.1 > > though that increases to 3.6 seconds if I run the self-tests. > > 24 tests (24 passed, 0 failed) > All tests succeeded! > Now cleaning up tmp files. > rm: Cannot remove any directory in the path of the current working directory > /export/home/drkirkby/sage-4.5.alpha1/spkg/build/patch-2.6.1 > Making Sage/Python scripts relocatable... > Making script relocatable > Finished installing patch-2.6.1.spkg > > real 0m3.635s > user 0m3.057s > sys 0m2.392s > > > 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 > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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
