On 2013-01-17, Keshav Kini <keshav.k...@gmail.com> wrote: > Dima Pasechnik <dimp...@gmail.com> writes: >>> 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? > > IMO, no way. We should not store upstream source in our repository > because we should not ever modify upstream source, so there is no reason "thou shalt noht ever modify upstream source" is not cut in stone anywhere. With revision control on, the very notion of "unmodified upstream source" becomes obsolete.
> to have it under our own version control. IMHO git-subtree allows one to retain the history of the original (sub)project, therefore it's not really our very own history? > Any changes we make to the > upstream source should be done by making patches. This is even the > reigning guideline right now, to say nothing of future plans. this sounds like a legal brief, but we're not in court, your honor :-) > > Rather than git-subtree, git-submodule might be appropriate, but > unfortunately it is rather opaque to git newbies, overkill for our > purposes, and assumes that submodules actually have version control > histories (GAP anyone?), yep, sure, GAP has a mercurial repo, they imported their cvs history AFAIK. I presume git can be made to import/export these. > not to mention that the way it is designed is > IMO very ugly (doesn't deal well with switching branches in the main > repo). > > What Robert is proposing is exactly what has worked just fine in Portage > for many years :) And probably in BSD Ports for even longer (though I > don't know anything about BSD). All my build scripts, patches, etc. are > in a git repository at /usr/portage, with a .gitignore'd directory > /usr/portage/distfiles containing "distribution files", i.e. mostly > upstream source tarballs. I don't find this an ugly hack at all - rather > I find it quite nice. oh no, of course it won't hurt anyone to learn yet another package management system, with all its bugs and features :-) My experience with package management systems is that they are nice as long as they work and someone else fixes them. But I also saw them dying, e.g. fink (a MacOSX GNU soft distribution system), and I saw them creating barriers for even mildly nontrivial things. > > My 2ยข. > > -Keshav > -- 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.
