[Debian-science-sagemath] Refactoring sagemath package

[Tobias Hansen]

Hi,

compared to the Arch package [1] our sagemath package is much more messy. We have more patches and much more complexity in the debian folder compared to the Arch PKGBUILD file. I would like to change that, since it's quite annoying to work with this mess.

I have identified several differences which make our package more complex than the Arch package:

1. We insist on running sage before installing it.

    Arch sets all the SAGE_* environment variables once and for all to the paths where sage will finally be installed. They are however not building the documentation and running the test suite during the package build. Since we insist on doing these things during package build, we have to set everything up in two different ways which leads to a lot of complexity and additional patching. I thought about ways to avoid running sage before installing it, but that would require an additional source package that builds the documentation and runs doctests, which is probably even worse. Right? Anyway, we have to try to improve the way we use the environment variables. And hope that upstream improves support for this scenario.

2. sage/mist/package.py and the pruner

    The only purpose of our debian/pruner script is to create the files in SAGE_SPKG_INST so that sage/mist/package.py can determine which packages we assume to be installed. For this purpose it is quite an overkill. I would like to remove the pruner altogether. Other distributions just patch sage/mist/package.py and don't really use it, but that results in additional failing doctests in various places. Ideally upstream would find a solution for this. At the moment every distribution has a different half-baked solution.

3. Multiple doc-packages

    This one is easy. We have a separate doc-package for every language leading to unnecessary complexity in the debian folder. Apart from the English package they are all quite small. Merging them into a single doc package would just result in a package slightly bigger than the current English package. Are there any reasons not to do it?

That are the main points I could think of right now. Of course the package also needs to be fixed and updated.

Best,

Tobias

[1] https://git.archlinux.org/svntogit/community.git/tree/trunk?h=packages/sagemath