Fwd: Advice on packaging SAGE
The following is a relevant discussion with William Stein on packaging
SAGE for Debian.
- Jordi G. H.
---------- Forwarded message ----------
From: William Stein <wstein@gmail.com>
Date: 29-May-2007 15:43
Subject: Re: Do you patch the upstream components of SAGE?
To: Jordi Gutierrez Hermoso <jordigh@gmail.com>, sage-devel@googlegroups.com
On 5/29/07, Jordi Gutierrez Hermoso <jordigh@gmail.com> wrote:
May I forward this reply to the Debian lists? They got lively when I
mentioned SAGE.
Sure! Please emphasize that in the long run I *really* want SAGE
to be part of Debian, that we are working very hard to make
sure that every component of SAGE satisfies their licensing
requirements (there is an issue with Tachyon3d right now, but
nothing else), and the main reason that we don't have various
.deb package for SAGE now is simply lack of resources.
---------- Forwarded message ----------
From: William Stein <wstein@gmail.com>
Date: 28-May-2007 22:31
Subject: Re: Do you patch the upstream components of SAGE?
To: Jordi Gutierrez Hermoso <jordigh@gmail.com>, sage-devel@googlegroups.com
On 5/28/07, Jordi Gutierrez Hermoso <jordigh@gmail.com> wrote:
On 28/05/07, William Stein <wstein@gmail.com> wrote:
> On 5/28/07, Jordi Gutierrez Hermoso <jordigh@gmail.com> wrote:
> > Just a quick question, the versions of Octave, Maxima, Pari, et al
> > that you have in SAGE, are they patched?
> Yes, they can be (or are) patched in small ways which the upstream
> versions might not even want to do. Also, that the versions be *exactly*
> right is important.
Oy... this introduces some difficulties.
(See below.)
> I wish somebody would make a Debian package that just installs
> everything into /opt first. Once that is done and working well, it
> would be time to think about what you're thinking about above.
It is trivially easy to make a dotdeb (i.e. a file with the .deb
termination that dpkg can extract and install), but it's more
Actually, I mean a dotdeb that has the property that the dpkg
tools have analyzed all libraries included in the package and generated
an appropriate dependency list. This is something those tools can
do automatically. It's not trivial to create such a .deb file that does
this, though it's probably not impossible -- in fact Bobby Moretti
did it in about 2 days last year. (Unfortunately he didn't maintain it
since he wanted to do mathematics instead.)
difficult to make a Debian package. Debian is quite strict about its
packaging policies. In particular, putting *anything* in /opt or even
/usr/local violates Debian policy for Debian packages.
I'm not suggesting make a .deb that would be hosted by Debian
at this point. I'm suggesting making something that we will host on
the sagemath.org website, which people can download and install
(or we could post a repository). Then the Debian guidelines can
be ignored (at our own peril, of course).
SAGE may need
significant modifications in order to play well with the Debian
packages for other bits of free software that SAGE depends on. I'll
ask in the Debian lists for advice.
To have SAGE accepted by the Debian project and
made "apt-get" able by any standard Debian machine
is a much more difficult problem. It's well worth tackling.
It is foolish though to tackle it before tackling the problem
of just making a monolithic -- installs to /opt -- SAGE debian
package. The main software SAGE intends to compete with
are Maple, Mathematica, MATLAB, and Magma, and none
of those programs even have .deb's of any flavor, let alone
are integrated into the Debian system (for obvious reasons).
Making SAGE easier to install than Maple,Mathematica,MATLAB, and
Magma on Debian systems should be our first goal, and I think
a monolithic .deb would address that problem. The next long-term
goal would then be making a different SAGE package, which builds
into a system-wide python2.5, part of the official Debian
repositories.
What are the nature of the patches to the upstream sources, btw? Are
they very significant? Why is SAGE so strict about what versions of
other packages it depends on?
Because it is mathematical software:
(1) With a GUI if you move a dot over by
one pixel in a new version of a library, it's no big deal. In math software,
if you change one bit in a new version of a library or software component,
it can cause thousands of things to go wrong. Since SAGE is frequently
used for serious research, this sort of thing is critical to guard against.
(2) Some of the components of SAGE tend to be somewhat unstable.
E.g., every single new version of Maxima tends to break numerous
things SAGE uses Maxima for. Note that several of the components
of SAGE are very much designed to be used as components in a
bigger system like SAGE.
(3) Getting SAGE to work together is quite difficult, since it's a complicated
system. Essentially every time I upgrade or change the version of any component
in SAGE, there are problems that I have to address. Getting everything to work
with numerous versions of Maxima (say) would lead to such complexity that
the project would not be manageable. As it is now, in a few hours I
can easily test
that everything works correctly together in tens of thousands of examples on
a bunch of different OS/hardware combinations. If I had to test that the
last five version of Maxima work with SAGE and the last five versions of PARI,
etc., the complexity would mushroom out of control. With most normal
libraries, this is an issue, but it is a manageable one since libraries have
well defined interfaces, etc. -- but programs like Maxima just don't work
that way.
-- William
Reply to: