On 2013-01-17, Burcin Erocal <bur...@erocal.org> wrote: > 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? both. And the Sage pexpect interface, which is not in the spkg, as you know.
> I presume the bug fix > produced in the end is intended to be included in Maxima. No, not really. The bug fixes produced included * unmerging a particular commit in Maxima master, (by providing a corresponding patch in spkg), and this was purely Sage-specific. And for this I needed to do a git bisect on Maxima master. * adding patches to spkg which are commits into Maxima master, or just patches proposed on Maxima bug tracker, some of them in response to our submissions. * patching Sage doctests. > In that > case, why not develop Maxima proper instead of just looking at it only > as a component of Sage? Huh? The fix I talk about above consists of creating a little custom fork of Maxima, and patching Sage lib. None of this is relevant to "developing Maxima proper". > >> 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. sure, this is a typical patchquilt thing; for some reason you think it's OK if it happens to an spkg, and not to Sage proper. > > 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. Why do you think that using git-sub* will preclude one from sharing fixes with upstream? One of the very purposes of git-sub* is to make this process easier, not harder! One would be able to produce a git patch ready for merging into upstream without any hassle that, you insist, is necessary... Best, Dima > > > 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.
