On Tuesday, 30 April 2013 22:35:18 UTC+8, Volker Braun wrote: > You shouldn't make patches by hand, its easy to make diffs between any two > revisions once you have checked in everything.
sure, I can do this. But I don't want to mess around with carrying over the spkg's metafiles/scripts hg history in a special repo. And if I can fake the history the way libGAP does, why can't I do the rest the way libGAP does it? > At least you have an > upstream source tarball, GAP thinks of itself also as a distribution of > mathematical software... > > Is its still under the "Common Public License"? IBM at one point agreed to > supersede it with the EPL. the license is imposed on the CSDP author by his employer. He told me he doesn't think it's possible to change. > > In the end, the question is whether you just want to build a spkg or if you > want to fork upstream. Both approaces have advantages and disadvantages. I want CSDP to be easy to build, both in and out of Sage. Actually, many files are touched, as I changed the layout of headers to make it easy to pick up with autotools. (and so #includes get changed too) Call it chopsticks... :) Dima > Volker > > > On Tuesday, April 30, 2013 2:18:49 PM UTC+1, Dima Pasechnik wrote: >> >> On 2013-04-30, Volker Braun <vbrau...@gmail.com> wrote: >> > ------=_Part_4004_20928279.1367304370235 >> > Content-Type: text/plain; charset=ISO-8859-1 >> > >> > Libgap also modifies each source file (global symbols are prefixed with >> > libGAP_...), so its not exactly a comparable situation. >> So if you modify files you can have it nice and easy, and >> otherwise one has to bite the dust making patches by hand? >> I beg to differ, I think that the ease of maintainance must take the >> precedence over a rigidly understood "unmodified source" principle, or >> whatever is left of it in this case. >> >> E.g. I remember debugging a version of maxima spkg a while ago, it was >> even >> not possible to find out exactly which point of maxima source tree >> the damn thing was made from... >> >> > I'd say if you just >> > change autotools / Makefiles then its easier to make it a patch. >> I find messing around with patches this way burdensome and error-prone. >> In particular this would mean maintaining two repos, one mirroring the >> changes in a part of the other one, instead of one. >> Instead, libGAP takes the route of saying: "it's not a real repo in the >> spkg, >> go to the real one if you want the history". >> So this must be OK in other spkgs, no? >> >> > If you >> > make heavy changes to the sources (is that legal in this case?) >> I don't see what can go wrong with modifying code under this licence and >> distributing it non-commercially. >> https://github.com/dimpase/csdp/blob/master/LICENSE >> >> > then it'll eventually become easier to make your own fork. >> >> well, it is all already done and waiting for a reviewer! >> Now potential reviewers are telling me to ask on sage-devel >> whether it's kosher to make spkgs this way... >> >> Dima >> >> >> >> > >> > >> > On Tuesday, April 30, 2013 4:05:14 AM UTC+1, Dima Pasechnik wrote: >> >> >> >> For http://trac.sagemath.org/sage_trac/ticket/14505, I needed to >> >> libtoolize a rather old source (unchnaged for last 6 years), to get >> >> rid of a bunch of messy Makefiles etc. >> >> Apart from that, the change was in the layout of include/. >> >> I imported the upstream svn repo into git, and put it up on github. >> >> While it's perfectly possible to make a cumulative diff against the >> >> upstream source, and use it to create the spkg, I rather prefer >> >> to use the modified source on the git repo. >> >> >> >> Another concern is the history of spkg-specific files; >> >> following libGAP's example I only provide a fake hg repo in the spkg, >> >> with the real history of changes documented on github. >> >> >> >> Any thoughts about this? >> >> >> >> Thanks, >> >> Dima >> >> >> >> >> >> >> > >> >> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
