Robert Bradshaw <rober...@math.washington.edu> writes: >> Well, considering among other things the recent discussions about >> licensing, I don't think that it's going to be possible to have a single >> top-level repository for all Sage code. > > But for everything not part of the upstream packages, licensing > shouldn't be an issue.
I'm referring to William's comments that the Sage library should be shipped under a different license from the Sage distribution as a whole (GPLv2+ and GPLv3+ respectively). I guess it's still possible to ship them together as a whole, though. But considering that we might one day want to make part of the Sage library possible to install into your system Python distribution (right?), it might be a good idea to keep it separate from the "infrastructure" part of Sage. >> I think ideally we should have >> three repositories, one for the Sage library (what is currently in >> $SAGE_ROOT/devel/sage-main), one for Sage packages (an aggregation of >> the repositories in all our current SPKGs, basically), and one for the >> Sage base system (an aggregation of the scripts repo and the root repo). > > Or we just have one repository--I'm still not seeing any advantage of > having multiple repos (and many disadvantages). > > [...] > > Being able to uninstall things, or switch between versions, would be > really nice but is somewhat orthogonal. (And yes, we could borrow > infrastructure here.) I think there are some advantages to keeping our package management separate from our mathematical library separate from our glue which binds the two together, namely that we can import the first (from Gentoo Prefix, say) and export the second (as a standalone Python package with optional dependencies on stuff which we currently depend on, say). Honestly I'm not sure how likely it is that the Sage library might one day be separable from Sage, but I've heard people say that it is a long-term goal. If that's not the case, we could consider it part of the glue (i.e. bundle it with the scripts and root repos), but I still think that we should keep the packaging subsystem separate to allow us to swap in other stuff like ebuilds for Gentoo, .deb packages for Debian/Ubuntu, etc., to keep open the prospect of one day finally being able to ship something that's not monolithic. Or maybe the long-term picture of Sage is going to turn out to be a VirtualBox VM on all platforms. Who knows... >> Related question: do we actually have a record of what versions of what >> SPKGs were released with what versions of Sage? For the standard SPKGs >> you can just look into the directory in the Sage tarball, but what about >> optional packages? > > This is information that should be in the revision control, ideally > switching spkgs as part of the same commit (set) as any modification > to the library or scripts. The repo would be the base + library + spkg > metadata (what upstream tarball + modifications + custom installation > scripts). I'm not sure that's such a good idea. We should be able hotfix SPKGs without having to hotfix Sage itself. Or to put it another way, the development of build scripts for packages shouldn't really be in lockstep with the development of Sage, the mathematical system, since we have no control over upstream releases or bugfixes. I see a future build-script repository as being something that people continually update from trunk to "check for updates". To avoid premature upgrading to new SPKGs that don't work with an old version of Sage, the Sage package itself would require certain versions of certain SPKGs and no higher. Of course, they would not pull from the Sage repository itself until an actual version was released. This is more or less how many Linux distributions work, i.e. package metadata / build scripts / etc. are updated constantly, and actual software packages have much more infrequent stable version releases. So for this to work the Sage repository would have to be separate from the packages repository. Another advantage of this is that people writing their own packages to use with Sage could more easily and quickly get their stuff into the Sage package repository as an official optional package, which goes well with what William (?) was saying somewhere on sage-devel recently about how the packaging system of Sage should allow people to write their own packages without communication with us. Though of course those people could always distribute files that would plug into our packaging system, having the package repository separate from Sage would also encourage it to be modular enough to make this feasible. Just some thoughts. -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
