On Thu, Jul 1, 2010 at 9:03 AM, kcrisman <kcris...@gmail.com> wrote:
>  > I propose that we make GNU patch a standard package, so that
> patches
>> > to Sage can be made in a more sensible manner than using 'cp' as now.
>> > (There's no point in 'patch' being optional at all, as it would be
>> > needed when building Sage).
>>
>> For the discussion, I believe David is referring to patches in Sage
>> spkgs (which currently consist  of the patched file, and are "applied"
>> by copying them over the original source file in the spkg src directory).
>>
>> +1 for the idea of inclusion.  I've wanted this for a long time.
>
> I won't vote because I don't think I am invested enough in how to do
> this, though it would have made my life easier a few times.  However,
> I do recommend that this should not be included unless it is
> immediately used in a few of the worst offending spkgs - otherwise it
> would seem sort of pointless.  Also, whatever ticket adds this should
> (in my opinion only) be required to update the source to
> http://www.sagemath.org/doc/developer/producing_spkgs.html in a very
> explicit way.
>
> I think drkirkby implicitly has said he will be doing these things in
> his updates for OpenSolaris etc., so probably it's a moot point, but
> no one had said this yet (in this thread).


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.  Also, no current spkg-install's have to be
changed at all.   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.

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

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

Reply via email to