On Tue, Feb 21, 2012 at 07:27, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Mon, Feb 20, 2012 at 6:45 AM, Keshav Kini <keshav.k...@gmail.com> wrote: >> Robert Bradshaw <rober...@math.washington.edu> writes: >>> But yes, this sounds like a great idea! So the >>> collection of .ebuild files (and their supporting patches, etc.) is in >>> the Sage repository, but periodically exported somewhere central >>> (owned by us? Gentoo?) that people pull from, right? >> >> Er, nope. The ebuild corresponding to the Sage library itself would be >> stored in the Sage repository, and periodically (upon the release of a >> new Sage version) be exported into our package repository. All other >> ebuilds and patches would be put directly into that package repository, >> which would be hosted live somewhere, say on github. Our package >> repository would look very similar to the current sage-on-gentoo >> repository, i.e. be a portage tree providing ebuilds. The other >> repository would be the Sage repository. > > I understand the purity of keeping ebuild files separate from the > source itself, keeping (exact) dependencies and metadata under a > single revision control, and viewing the Sage library itself as just > another package, this still means one can't do > > git checkout trac-12345 # or pull from remote, etc. > local/bin/sage -b > > for tickets spanning package changes. Perhaps something with git > submodules (fake or otherwise) or overlaying one portage directory > over the other could make this possible.
Are you sure? It seems to me like it's perfectly possible to do $ git checkout trac-12345 $ emerge --sync # equivalent to `git pull` in the package repo $ sage -b The following would occur when you did `sage -b`: 1. sage-9999.ebuild would be copied out of the Sage library tree, specifically out of the tree of the revision at the head of the trac-12345 branch of the Sage library repository 2. This sage-9999.ebuild would be placed in the portage tree (not under version control, but just dumped there), in say lmonade/dist/portage/sci-mathematics/sage/ 3. `emerge =sage-9999` would be called, thus explicitly building sage-9999.ebuild 4. Since sage-9999.ebuild came from the revision at trac-12345, the dependencies listed therein would include the correct versions of packages required for that trac ticket; the authors of the trac ticket, at the same time as committing the changed sage-9999.ebuild into the Sage library, would have also committed updated ebuilds for the new packages required, into the package repository. Or those updated ebuilds would already have been committed there earlier. Thus they would now be pulled in by the building of sage-9999.ebuild. This seems to be pretty much what you want, right? The only catch I see is that possibly there might be delays in getting the new ebuilds into the package repository, whereas publishing your topic branch of the Sage library is instant. But since it's supposed to be a rolling release repo (unlike the Sage library repo), hopefully this won't be so bad. And if the ticket author is really impatient, he can publish his own branch of the package repo too, for you to pull from before running `sage -b`. > Upgrading to the latest alpha > (or even more find-grained versions) would be "git pull" which is > something that's also really lacking in our current workflow. All of > this requires a repository. One could upgrade to the latest alpha by just pulling with the above setup, too. The point is that the package repository would contain all past and future versions and patch versions of packages, within reason (maybe we would delete extremely old versions). So even if you had an old version of Sage, the newest versions of other packages would already have their ebuilds in your package repository, even if you hadn't been able to install them due to your old version of Sage requiring older versions of the packages. Once you pulled the alpha into your Sage library, sage-9999.ebuild would now let you install the new package versions. And if you checked out your old version of Sage again, those packages would be downgraded again the next time you did `sage -b`. > Of course, there's also the question of bootstrapping itself. Would > lmonade itself be shipped with Sage? What about versioning this piece > of software? lmonade bootstraps itself and installs Sage from the included ebuilds. So that would constitute our source distribution, I imagine. Binary distro would be similar except we would pack binary versions of the packages instead of source versions. Portage (and thus Prefix) has ways to do this, but I'm not very familiar with binary packages in portage. I'm also not sure how we would do version control there. I guess the lmonade bootstrapper / installer would be created with a `sage -sdist` or `sage -bdist` command, just like we currently are doing, in which case the relevant files would be under version control wherever the other Sage scripts were. I haven't put much thought into this though. -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
