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. - 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.
