Le 09/03/2013 11:09, Sylvestre Ledru a écrit :
On 09/03/2013 10:14, Julien Puydt wrote:
Package: maxima
Version: 5.29.1-1
The maxima used in sage is built with ecl, while the sage in debian
isn't. That will of course be a problem to package sage ; a very simple
fix would be to just compile maxima with ecl in debian.
But of course, simple doesn't mean correct : I saw #661803 where someone
asks for an sbcl-built maxima, so the situation is going to be a pain if
each and everyone wants maxima built against some variant of common lisp...
I don't know how to handle the situation gracefully, so I open this bug
CCing debian-science to discuss the matter.
Usually, during the package creation workflow, you rebuild the
application against the various implementation and you provide:
maxima-implementationX
maxima-implementationY
maxima-implementationZ
It takes a X time more time to build and it is harder to maintain: paths
have to be different or packages have to conflict one against the other
(causing issues for the packages depending on this).
(example: hdf5)
More time to build, bigger size in the repository, and a general pain, I
know ; that's why it has to be discussed and good choices have to be made.
My advice: see if sage can work without this.
Here is how I see things looking at the code from high above :
(1) sage/libs/ecl.pyx has some code to convert between ecl and sage
basic types, initialize some things, control the gc...
(2) sage/interfaces/maxima_lib.py makes the interface between sage and
maxima, and heavily uses ecl.
In fact, the impression I have is that sage isn't using ecl through
maxima (which would make it quite easy to hide something else behind
maxima), but is using maxima through ecl. That means getting ecl out of
sage is basically a fork...
How easy is it to make the same maxima to run on several common-lisps?
Snark on #debian-science
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
