Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
Hi there.
On Thu, Apr 11, 2013 at 11:41:17AM +1200, François Bissey wrote:
> From the point of view of a linux distribution, my opinion is that the package
> management system should be extracted. If it comes from your distro the
> packages and upgrades are handled by the distro mechanism, except for stuff
> that (can) live in the final user home directory.
i do not really understand this. are you saying that the linux
distribution should take over the role of the sage package mechanism? if
so, would that mean that sage components should work independently of
the sage packaging method?
> Sage itself has currently several components that are shipped separately and
> at least one that should be split:
> sage_root: which has all the elements of the basic build system and
> traditionally the scripts to start sage.
> sage_scripts: a collection of various scripts and command to run and tests
> sage.
> extcode: various bits and pieces accumulated over time. I understand it will
> disappear in the git migration being integrated elsewhere.
> sage: the python extension itself plus the c library. The c library is the
> element we think should be split (and we do in sage-on-gentoo).
are you implying that its a good idea to split components and ship them
as seperate packages? the sage-to-git transition apparently does the
reverse. how does this affect the gentoo-packaging?
> Whether to keep this structure in Debian or after the git transition is not
> for me to answer. But I strongly believe the c library needs to be available
> separately from the python library.
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?
> The c library is built with scons which
> has its detractors (that includes me) but is seriously too small to justify
> autotooling in my opinion.
all i (need to?) know about scons is, that there is no visible concept
of configure. particularly there is no way to pass
--with-this-and-that=/my/favourite/path switches in a practical way. so
if the c_lib is small, that would make transition to something else
even fast.
> > It would still be nice if the top level script could be used by
> > distributions. There are still several things to build and other things
> > to do, if external dependencies are not built, and we should not
> > implement all this in debian/rules. One could start with the option to
> > build all or none of the dependencies and then maybe go further to allow
> > more combinations. But I'm also not entirely sure if combining system
> > and bundled dependencies is needed. Maybe an alternative build script
> > for building with system libraries would be a better idea. Are there
> > other opinions?
> >
>
> The questions has arisen several time in the past 5 years but in spite of some
> suggestions on how to achieve this, no one has done the work. You are welcome
> to have a go at it. If you start it you may get a surprising number of
> helpers. I think most of the inertia is in starting it.
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).
have fun
felix
Reply to: