On Thu, Jul 1, 2010 at 2:43 PM, Georg S. Weber <georgswe...@googlemail.com> wrote: > 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 ...
My proposal is very vague and leaves a lot open to interpretation and nailing down details. Your suggestion above is definitely one possible way to go. Thanks for making it. 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
