On 12/04/13 20:59, Tobias Hansen 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. > > Only if we want multiple Sage "Debian source packages". > >> 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? >
I'd like to note that on gentoo we only use things like sage-singular-xxx as an exception - singular is a particularly good example, since it was the last one we had years ago. Compared to debian we have a little bit more freedom on the versions a user can install. My own experience over the years is that singular and pari are possibly the most problematic one followed by polybori (but it is improving dramatically in that regard in the latest release), networkx and lately ppl. The biggest reason of doing sage-foo for everything is to use mpir instead of gmp. sage-on-gentoo is using gmp as switching to mpir distro wide would require agreement from the toolchain people. There are way of giving people the choice but that involves changing every package currently using gmp.... Francois -- 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.
