On Wed, 7 May 2008, Kapil Hari Paranjape wrote:
The primary problem that makes my packages potentially unsuitable for uploading to Debian now is many of them may violate Debian library policy:Last time I looked at the problem of packaging SAGE, there was one other issue. SAGE required certain libraries/programs to be "fixed" at certain upstream versions (with/without additional patches) in order to ensure compatible behaviour. For example, SAGE wanted a particular version of "gpari" with some patches. The actual version of "gpari" in Debian is different. If this has changed, then please correct me. Otherwise, it raises a host of issues which would cause the package(s) to be incompatible with Debian.
The SAGE folks ship a bundle with all their dependencies that they've tested completely, because it allows them to fix any bug in SAGE, regardless of whether the problem is in SAGE itself or one of their dependencies, and helps them limit the amount of time they spend debugging problems the developers can't reproduce. So, they definitely tell anyone who asks about running SAGE with their own "gpari" that it's not a supported configuration.
In my experience running with whatever version of these packages is in Debian Lenny, the SAGE code doesn't rely heavily on a particular version of a dependency. They do often include the latest versions of their dependencies, however, and the SAGE code sometimes starts using new features in these dependencies fairly quickly. So, for example, my repository has at various points in time contained updated versions of cython, zodb, and matplotlib asking for them to update to a new version because SAGE used interfaces new in a later release than that available in Debian. Cython should perhaps be considered an exception here because its development is tied to that of SAGE. So, I've needed newer versions of 2 of the 50 packages already in Debian that SAGE depends on.
SAGE also does maintain patches against upstream packages, though they have been working hard during 2008 to get their patches merged upstream (I think in part inspired by the fact that this needs to happen for SAGE to be packaged as anything other than a giant blob). Most of these patches go away with the next upstream release; it's not the end of the world if the package for SAGE in Debian keeps using that buggy gpari (or whatever) package until upstream merges the fix. My packages at present only apply a few patches against the upstream sources (though I obtain my upstream sources from SAGE's upstream portion of their spkgs; in most cases these are in fact clean upstream but I think a few are pre-release versions of the upstream because the upstream developer is working on SAGE).
So, while I think that version issues was a big problem 6 months ago, I don't think it's a big problem now.
This aspect of SAGE seemed to make it more appropriate for a Custom Debian Distribution rather than a package. It may be easier to start this way in any case given the complexity. Over time, after co-ordinating with the developers of SAGE dependencies within Debian it should be possible to fold all the packages back into Debian. (Ref: demudi and texlive)
I'm not familiar with how CDDs work. Reading the description at <http://wiki.debian.org/CustomDebian>, I'm not certain what running a CDD actually entails (the website talks about a lot of issues involved, but not about things like what apt repository CDD packages live in, how users install them, etc. -- maybe this depends on the CDD?).
-Tim Abbott