The following is a relevant discussion with William Stein on packaging SAGE for Debian.
- Jordi G. H. ---------- Forwarded message ---------- From: William Stein <[EMAIL PROTECTED]> Date: 29-May-2007 15:43 Subject: Re: Do you patch the upstream components of SAGE? To: Jordi Gutierrez Hermoso <[EMAIL PROTECTED]>, [EMAIL PROTECTED] On 5/29/07, Jordi Gutierrez Hermoso <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Date: 28-May-2007 22:31 Subject: Re: Do you patch the upstream components of SAGE? To: Jordi Gutierrez Hermoso <[EMAIL PROTECTED]>, [EMAIL PROTECTED] On 5/28/07, Jordi Gutierrez Hermoso <[EMAIL PROTECTED]> wrote:
On 28/05/07, William Stein <[EMAIL PROTECTED]> wrote: > On 5/28/07, Jordi Gutierrez Hermoso <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
