Since Sage already has lots and lots of "batteries included", I agree to say that we should be careful about whether additional spkgs are really needed.
I vote "-1" to the inclusion of an additional "patch.spkg". May I assume there is consensus about mercurial (once successfully installed) provides all the functionality that an additional "patch.spkg" would provide (maybe even make vanish WIndows/Unix differences in line ending char conventions in "diff" files, which probably is an issue for a "plain patch")? If so, reading through the arguments above, such an additional "patch.spkg" would only be really needed if both of the following holds: a) patches have to be applied to a spkg that is a build dependency of mercurial b) these patches have to be created from diffs during the build, i.e. are not already contained in this spkg Currently, such patches are shipped with spkgs, so this situation does not occur because "b" is not fulfilled. And even if at some point in the future, we opted for reducing the size of sage tarballs by throwing out patches inside spkgs, and keeping only the diffs, then still those spkgs which are build dependencies for mercurial could be excluded from that rule (python itself is one, of course, but hopefully does not need to be patched forever. OTOH, the vast majority of the 100 or so spkgs in Sage aren't build dependencies for mercurial). As William started to point out, the desire to enhance the current way "/patches" is used, does not necessitate an additional "patch.spkg" either. Of course there is room for improvement in the way the "/patches/" subdirectories of spkgs are handled. If asked for a proposal, I'd answer that we should have under "/patch/" diff files "20100101.diff", "20100202.diff", ... that are to be applied in the order given by their names, creating a certain set of patches (patch files). These patch files are being stored directly under "/patch/" unless there are two with exactly the same names, or some files ending in ".diff" (but only then), in which case these are stored in a subdirectory structure under "/patch/src/" mimicking "/src/". Only the diff files need to be in the spkg revision history, the others are created manually (or by some automatism during spkg creation --- I would vote against removing the patch files fom the spkgs, it's just too convenient to have them right there at hand). All files under "/patch/" except the diff files get copied over during the build of the spkg, the code doing this could be rather generic (needs only to check into which subdirectory of "/src/" those "non- diff"-files lying right under "/patches/" are to be copied to), and needs not be part of the spkg-install's, but could be called from these. But I think we already have too many proposals floating around in this thread ... Cheers, Georg -- 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
