Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
On Thu, 11 Apr 2013 22:27:48 Felix Salfelder wrote:
> 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?
>
Yes. Do you as a distro packager want one of your applications take over the
management of some of your system components? Never mind that it would
probably need privilege do to so. Sage package mechanism include upgrade
capability. Do you want a sage debian package just upgrading itself by
compiling bits all over the place independently of dpkg? Never mind that would
probably mess upgrade and fixes from dpkg.
> > 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?
>
We'll change the way we package things. The current packaging in Gentoo
reflects the packaging upstream to a great degree apart from the separation
of c_lib. This separation is motivated by the fact that c_lib and the python
library have two different build systems and it is hard to combine them
in a single package from the Gentoo point of view. Another point for me is
that c_lib is a rather slow moving thing not updated very often. The other
packages are just plain files to install.
Separating c_lib in its own package with its own version numbering may enable
me to provide several version of sage on the system at the same time.
That last bit is very much more of a wish than something concrete but this
separation would make things easier. There are a lot of other obstacles.
> > 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).
>
No arguing there. Of course I am not doing a binary distro :)
> 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 python modules need c_lib but the reverse is untrue. It is one of these
things where either can be done depending on your agenda.
> > 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 is small. I often thought of just building it with a simple Makefile rather
than scons.
> > > 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.
>
I am already not using it. I guess the situation has gotten very different than
5 years ago.
Francois
Reply to: