On Jul 2, 2010 8:02am, Adam Webb <maxthemo...@googlemail.com> wrote:
I felt that the important part of the proposal was the use of patches.
Yes.
I don't know if there will really be a lot of space saved but I think
that is less important.
Agreed. But the point I would make is that just removing two of the huge
python patches would save more than the space that 'patch' would add. This
is just to counter the argument "it makes the download bigger". As I
pointed out, 'GNU patch' is very small (a Sage package is 251 KB) and on my
3.33 GHz Sun Ultra 27 I am able to install the package I made
http://boxen.math.washington.edu/home/kirkby/patches/patch-2.6.1.spkg
and run all the self-tests in under 4 seconds.
The advantage of patches as I see it is that
it is a well known and used method of making changes to source code.
Yes. Though I've nothing against using a better method if it is not well
known.
Having the original source and applying patches is the logical thing
to do.
The question seems to be when to apply the patches. Can the patches be
applied when the spkgs are made? Are there patches which are applied
conditionally at install time?
Yes, when to apply the patches is important. As far as I can see, several
can only be determined based on the build-time environment.
My personal preference is to patch as late as possible. When I get the
spkg I want the original source and not a patched version. Then I
still have the option of adding/removing/changing patches as needed
for my system.
Unless there was a very radical change in Sage, I think this is best.
Currently when something does not work, commenting out lines which apply
patches is a useful way to sort out if a patch has caused the problem. That
opportunity would be lost if the patches were already applied.
If I understand the proposal.
1. the diffs are made and included in the patches directory (details
of naming aside)
2. when sage -pkg is used the patched files are created
2b. conditional patches for specific systems and OS's could also
made (do we expect a lot of these?)
There are many patches in Sage which are applied on one or more operating
systems, but not all operating system. Often the same patch could be
applied on all systems, but it would make testing the patch, and so getting
it reviewed, a lot more difficult. So one only applies it on one system,
It's a fact of life that any change has a non-zero probability of causing a
bug, so it is often safer to make the patches specific to the system on
which a problem is seen rather than to apply them everywhere.
Some things I'm aware of that affect whether a patch is applied or not
include
* Operating system
* Whether the processor is Itanium or x86 on Linux.
* Whether the processor is SPARC on x86/x64 on Solaris.
* Whether the processor is the older sun4u or the more modern sun4v SPARC
processor on Solaris systems.
* Whether the build is 32-bit or 64-bit
* Whether the linker is the Sun linker or the GNU linker.
* The value of an environment variable.
There may be other things which determine if a patch is applied or not.
3. When the package is installed the patched files are copied over as
they are now
The bigger changes would be in the sage -pkg mechanism. The spkg-
install would also have to have conditions to copy the correct patches
for a specific system or OS but that is already the case.
It seems like William's suggestion would need a major change to how
packages are created. That would be a lot of work. In contrast it took me
about 30 minutes to put
http://boxen.math.washington.edu/home/kirkby/patches/patch-2.6.1.spkg
together.
The question then is if it is a burden to carry around the patches for
different systems. However, isn't this already the case?
Adam
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
