On Mon, Feb 20, 2012 at 8:21 PM, Keshav Kini <keshav.k...@gmail.com> wrote: > 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`.
This is exactly the issue. Currently, a ticket is not merged until it has been reviewed. Otherwise the options are to (1) give everyone who wants to contribute commit rights to the package repository, pushing *before* any review or (2) wait for manual intervention by someone with permissions to push to the package repository, again before a review or (3) publish your own branch, separate from your library changes, with instructions to pull from that or (4) post a patch file, like we do now. Completely independent from the packaging/building issues, throwing a second repository into the mix significantly complicates things. (On another note, I would like the Sage library repo to be a rolling release as well, at least as an option. Named releases are important as well.) >> 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`. Yes, this would work, provided the two repositories are manually kept in sync (or, specifically, the package repository is at least as fresh as the library repository). There is the significant advantage that things won't silently break if they're not in sync, and it's nicer in the case of alphas than pre-reviewed tickets, but it's still back to the issue of Sage being the union of two repositories that evolve together. >> 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. Hopefully the authors have, as this is a key point of any packaging system. - Robert -- 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
