On 2013-04-30, Volker Braun <vbraun.n...@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.
