On Thu, 17 Jan 2013 11:31:41 +0000 (UTC) Dima Pasechnik <dimp...@gmail.com> wrote:
> On 2013-01-17, Burcin Erocal <bur...@erocal.org> wrote: > > On Thu, 17 Jan 2013 07:17:43 +0000 (UTC) > > Dima Pasechnik <dimp...@gmail.com> wrote: > [...] > >> This still looks like an ugly hack. Shouldn't we rather use > >> something like [git-subtree] > >> (https://github.com/apenwarr/git-subtree/) to deal with upstream > >> source? > > > > git-sub{tree,module} is too much. As long as there is an easy way to > > get at the source and work with it, there is no reason to import the > > source code from other projects into our repository . Note that I am > > even trying to keep the packaging stuff out. > I gave above a good reason (debugging a Maxima spkg within Sage), I > think. Were you debugging Maxima or the Maxima spkg? I presume the bug fix produced in the end is intended to be included in Maxima. In that case, why not develop Maxima proper instead of just looking at it only as a component of Sage? > Even more to the point would be spkgs which are more or less a > part of Sage, such as libGAP. > Note that libGAP spkg at the moment ships a large chunk of patched GAP > spkg. So basically one has 3 source trees to coordinate, manually, > two of them overlapping quite abit, if > git-sub* is not used. > (And also, actually, GAP spkg has nontrivial spkg dependencies.) > > Another example is eclib, which (probably) most users use from Sage. > > Indeed, there are spkgs that seldom get really worked on, such as gcc > or python, but it does not mean that the rest should be locked into > the same inconvenient model. > > > > > lmonade can check out the upstream sources and compile it for you > > under devel/<package_name>. This gives easy access to upstream > > sources for debugging, encourages people to submit patches/pull > > requests and ask for reviews from upstream developers. > > > > Once you have an improvement, you can either export it as a patch > > and add it to the package Sage depends on, or if it is complex > > enough, create your fork on bitbucket, github, etc., point the live > > ebuild there and make Sage depend on that. > > And how do you coordinate this with the eventual changes in the Sage > lib proper? By trac comments? SPKG.txt? Mark that the Sage package depends on version >= <foo>. Where version does not have to correspond to an upstream release. It might have a revision tagged on that indicates your fix. For example, Sage depends on lcalc built with pari and the patches specified in the ebuild: https://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/sage/sage-5.5-r4.ebuild#L28 See the line ">=sci-mathematics/lcalc-1.23-r4[pari]" Here is the lcalc ebuild: https://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/lcalc/lcalc-1.23-r4.ebuild > Why not use git-sub* for this? > This is what looks the most bothersome point to me. This bothersome process is how the free software ecosystem works. If you benefit from the source some people bothered to put out there, then spot some errors and fix them, you should also take some trouble to share these with others, not only with users of Sage. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
