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. 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. > >>> It would still be nice if the top level script could be used by > >>> distributions. [...] > > > > i'm not convinced. once all parts (including python-sage and c_lib) are > > in a distributable/configurable shape, any distribution will be able to > > pick them up easily. especially there will be no need for distributions > > to use sage's built in top-level script. > > > > whatever a top level script does, it will never fit the needs of all > > distributions at once. just think about building a multiarch ready > > package out of c_lib, while it is only accessible within a tarball > > containing the sources of five other packages, through a patchwork of a > > sage-toplevel script and an spkg-install script calling "scons install" > > through a static makefile (or setup.py or whatever). > > Sounds reasonable. Would you take care that the Sage distribution also > build python-sage, c_lib, etc using the new configurable process? that would be the primary objective. treat python-sage, c_lib, sage-scripts, extcode, whatnoteverelse as *packages* just like all the other packages. now understand the sage-toplevel repository as a sage distribution (distributing spkgs or successors). sage will be distribution-friendly as soon as all packages have sane build systems. regards felix -- 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.
