Robert Bradshaw <rober...@math.washington.edu> writes: > On Mon, Feb 20, 2012 at 8:21 PM, Keshav Kini <keshav.k...@gmail.com> wrote: >> 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.
Yeah, this is not a great situation. If I had to choose among the four options you enumerated, I would choose (2). If I'm not mistaken we already have "maintainers" of SPKGs, so it would be comparable to that, but I agree that it would be better if you didn't have to go through a maintainer in order to add a patch to a package, or even generally if you didn't have to publish your experimental new patch setup to the public repository which everyone is pulling from, even if it were a patch setup that nobody would ever actually use, thanks to strict version dependencies. And that last requirement moves us towards picking (3), which is an awkward situation. You're right, this is starting to sound too complicated again. Hmm... I will have to think about this some more. > (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.) Sure, that shouldn't present any difficulties with Prefix as far as I can see, as long as we keep a public repository, which is something that we are very far from doing right now, what with Jeroen destroying all development releases after they become outdated, and all, but is something that should definitely happen once we switch to git, thankfully. >>> 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. You're right. This idea could be improved. -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
