First a disclaimer: I was at Sage Days 47 (working on the transition to git), but I'm not a git expert and I don't know the technical justification for some of the choices made (I think the best people to speak up in that direction would be Andrew Ohana, Keshav Kini, Robert Bradshaw, Timo Kluck or Julian Ruth). I also use OS X so I personally have no interest in working on packaging efforts, though I'm grateful to those of you who do, both for the increased exposure of Sage in the Linux world and for the progress toward the goal of being able to checkout different versions of Sage with different spkgs installed and have them build and work.
But speaking as someone who contributes a lot to the Sage library itself, I'm strongly in support of Robert Bradshaw's proposal that we combine the different Sage repositories (root, devel, script and ext). It's much easier to work on issues that involve code in these different repositories once you only have to make a commit to a single unified repo. On Fri, Apr 12, 2013 at 2:59 AM, Tobias Hansen <than...@debian.org> wrote: > Am 12.04.2013 10:25, schrieb Felix Salfelder: > > Hi there. > > > > On Thu, Apr 11, 2013 at 11:48:17PM +0200, Tobias Hansen wrote: > >>> so theres the inevitable question to ask: > >>> would it be an option to eventually split c_lib and the python modules > >>> to different packages? > >> > >> If they are each in a selfcontained folder it's not too much hassle to > >> repack them from the one tarball. (Ok, still some hassle.) However, I > >> don't see why they should not be in one source package. Because linking > >> to c_lib has to be done differently when it is not installed on the > >> system when the package is built? An important implication of having > >> stuff together in a source package is usually that they have to be > >> updated together. That is the case for the parts of Sage. By the way, > >> does c_lib have a stable ABI so that it is reasonable to have it as a > >> public shared library? Would that be useful? > > > > i don't see the c_lib/python sage lib as critical as the gentoo people > > do. but: if some distribution -- for whatever reason -- > > requires/fancies seperate packages, seperate packages would make sage > > more distribution friendly. (no actual problem here). > > > > what frightens me is that the spkgs for the core parts have vanished in > > https://github.com/sagemath/sage.git (the git-transition). if this is > > serious (and not a temporary kludge), we really would have to repack > > tarballs. > I'm not sure whether the spkgs you refer to correspond to the four repositories I mentioned above, but if so then the merging is intended to be permanent. > > > this (imo) is not just 'some hassle': try to cherry-pick a > > patch from current sage-python that makes the release candidate work > > with, say singular-(sage-singular-version+0.0.1). this scenario is > > realistic, as it doesnt seem possible to always ship exact dependencies > > within debian/gentoo/whatever. now try to cherry-pick that patch after > > repacking and loosing history. im not saying it's not possible. but it > > would be seriously distribution-unfriendly. > > > > To the git transition team: Have you considered using git submodules for > the different Sage components? It would certainly solve this issue. > Would it also have other advantages? Is there a reason not to do it? > Exactly what do you mean by "different Sage components?" I do know that there was some discussion of git submodules, but it was discarded for technical reasons that I don't recall. David -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
