On 2013-01-17, Robert Bradshaw <rober...@gmail.com> wrote: > On Wed, Jan 16, 2013 at 6:13 PM, Dima Pasechnik <dimp...@gmail.com> wrote: >> On 2013-01-16, Volker Braun <vbraun.n...@gmail.com> wrote: >>> ------=_Part_588_6290856.1358340327889 >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> I guess there are at least two different meanings of "the Sage tarball" in >>> this context. I was talking about the sum of all code checked into the Sage >>> repositories, which is what one would usually call the release. And the >>> third party code is not going to be part of the git repo under the current >>> proposal. >> >> I don't see how this would be an improvement as far as 3rd party code spkgs >> maintainance/updating is concerned. Are you saying it stays under the >> same ugly patchquilt model? >> Or everyone rolls his/her own spkg repos on bitbucket or github or >> whatever (as you do for libGAP)? >> >> Mind you, when I worked on the latest Maxima update (#13364), I had to do git >> bisect on *Maxima* repo to debug *Sage*, and then apply the results of this >> investigation to stripped of .git/ Maxima source tree, for which I did not >> have an exact mapping back to Maxima repo. >> It goes without saying that this is rather ad hoc, error-prone, etc etc. >> And then, when Sage patches (which are often experimental upstream's patches) >> for the spkg are merged upstream, a similar >> error-prone manual labour toil, sweat, and tears will be needed... > > Expanding on http://wiki.sagemath.org/WorkflowSEP one would have > > sage_root/ > sage # the binary > Makefile # top level Makefile > (configure) # perhaps, eventually > ... # other standard top level files (README, etc.) > build/ > core/ # sage's build system/bootstrapping > pkgs/ # install, patch, and metadata from spkgs > maxima/ > pacakge_manager_file # emerge or whatever, would point > to some upstream source, patch1.diff, etc. > patch1.diff > ... > ... > > A single commit would remove create patch1.diff and modify > pacakge_manager_file to use it, when patch1.diff is merged upstream, > we would do another commit to point pacakge_manager_file to the newer > upstream and remove patch1.diff. Here "upstream" is ideally an > upstream-provided src tarball (though we might distribute it > ourselves) and relating that to whatever revision control system they > use is out of scope.
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? Best, Dima > > - Robert > -- 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.
