Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly

[Tobias Hansen <thansen@debian.org>]

Let's drop debian-science from CC. For those interested, the thread on
sage-devel is at
https://groups.google.com/forum/?fromgroups=#!topic/sage-devel/1HGbf4EZGb0

Am 11.04.2013 22:27, schrieb Felix Salfelder:
> in debian, one source package can create multiple binary packages.
> this for example makes sense, when seperate (but related) lib*, *-dev,
> *-doc, *-dbg packages are convenient. packing unrelated stuff from a
> single source repo do different binary packages usually leads to
> overhead within the rules (which will probably not even work for the
> next release).
> 
> 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?


> 
>>> 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?

Cheers,
Tobias