Hacker News new | past | comments | ask | show | jobs | submit login

In 2007, Tim Abbott (before founding ksplice and zulip) beautifully and properly packaged Sage for Debian, and in fact Sage was included in Debian standard! Unfortunately, he stopped working on the project (when he started those projects), and of course we had no money to hire somebody else to maintain what he did. If I had money, it would be a total no brainer to spend it on supporting packaging SageMath for Debian. Your remarks about it being impossible because of our package manager and dependencies aren't correct, because things we the same in 2007.



OK, more accurately I should have said "much much more cost than is necessary", instead of "impossible".

The point is that, it should not cost significant continual effort to package SageMath for Debian: if SageMath was following good engineering practises, then Tim Abbott's work would still function today, even taking into account necessarily but normal and minimal maintenance costs that Debian volunteers (including myself) would be happy to do for Sage.


Tim Abbott here :)

The challenge of packaging Sage was primarily around packaging its dozens of dependencies (some of which I had to talk to the authors to fix their licensing terms) and making sure that an up-to-date version of those dependencies was available in Debian. It took about a month of my time to package Sage well for Debian (at the time I maintained over 100 Debian packages for MIT, so I was quite efficient at this).

What killed my Debian packaging effort was that Sage was very large and my package was submitted to the NEW queue (where Debian does copyright review) when all the reviewers were busy with managing a release freeze. So it took more than 6 months for Debian's FTP masters to fully review it, and by the time they did, I had moved from being a grad student to the CTO of Ksplice. It probably would have been just week or two's work for me to update Sage across those 6 months, but running a startup is a lot of work, and I never found the time to do that work :(.

Overall, my opinion is that Sage is well-engineered and not difficult to package given its scale (it has a fantastic test suite, so it was very easy to check if the package worked, and it was easy to get them to merge changes to improve the tooling). The problem is that it's a large project, with a large number of diverse dependencies, new versions of which aren't always backwards-compatible upgrades. If you talk to the folks who package other large projects for Debian, I'd be surprised if you find any that don't involve significant maintenance work.


More details here: https://wiki.debian.org/DebianScience/Sage

It would be great if you do pay someone to work on this, but please also keep in mind my points about continual costs. To reduce these, Sage upstream (you) does have to change some of its practises.


"Sage upstream (you) does have to change some of its practises"

This is also being worked on and there's progress being made.

I'm still pushing to completely separate Sage-the-library from Sage-the-distribution. There's been a little pushback but nothing that can't be overcome with basic configuration management practices.


I'm actually one of the few people being paid to work on Sage, and this is one of the tasks I have interest in.

Although my personal work is more focused on Windows support for the time being, this is definitely on the docket. We had a workshop about two months ago in France focused specifically on packaging Sage, and there are some excellent folks from LogiLab who are making serious progress on the Debian packing. I hope to circle back around to that myself after I've made more progress on Windows.


Great! Could you elaborate what LogiLab are doing? There is creating .debs, and there is creating a .dsc source package for inclusion into the official Debian archives. If you guys want to do the latter, you should talk more to the other people mentioned here:

https://anonscm.debian.org/cgit/debian-science/packages/sage...

The main barrier at the moment, is that sage patches many dependencies. It is better to upstream those patches, not only because it's good engineering practise, but also because it's unlikely that Debian policy (in practise: the admin, infrastructure, and security teams) would allow us to include (e.g.) a duplicate maxima-with-sage-patches in Debian, just to satisfy Sage.

OTOH if you "just want to" create .debs, the task is much easier. But then there's no chance of it entering Debian officially.


No, the goal is to have it actually in Debian. One argument that's been made against this is that Debian moves to slowly, and an old (but supported!) version of Sage is not useful to its current core user base of research mathematicians who often need the bleeding edge and/or are developing new code directly in Sage.

My counter argument is that we want to expand Sage's user base beyond a small core of researchers, and improve its usability as a Mathematica replacement for students and some scientists who are less interested in things like bleeding edge combinatorics research (they might be but not necessarily the majority). As a Mathematica replacement Sage isn't there yet, but it's good to get a head start on making easier to package and install, as part of that effort. Like for me, if it can solve some differential equations for me and do some integrals I don't care if the version I got through apt is a couple years old.

As for the upstream issues part of the problem there is that some of the upstream dependencies of Sage refuse to accept patches needed for them to integrate with Sage. That's a long story. I think the best approach there, which has already been tried in past approaches to patching for Debian, is to maintain Sage-specific forks of that software that include the necessary patches (IMO they should also be swappable with the originals via update-alternatives if possible). As far as I know there's nothingf legally preventing that, but more the effort involved in maintaining a fork and a package for that fork.

In the long term, I think, it would make sense to completely replace and rewrite some of the code that these external dependencies are used for. But in many cases there's an enormous amount of work involved, and that would only be possible with significant funding. And quite possibly not worth the effort compared to other ways that effort could be spent.


Perhaps we should continue this by email - you can contact me at infinity0@debian.org

> Debian moves to slowly [..] My counter argument is that we want to expand Sage's user base [..]

Beyond that - "too slowly" applies only for "Debian stable"; and users that are OK with less stability can use "Debian testing". Usually this is quite bug-free; things only enter testing if it's been in "Debian unstable" bug-free for 5-10 days.

It's also much easier to get your software into Ubuntu, if it's already available in Debian testing/unstable - and that would likely expand your user base quite a lot.

> some of the upstream dependencies of Sage refuse to accept patches [..] [we could] maintain Sage-specific forks of that software [..] swappable with the originals via update-alternatives if possible [..] [or] completely replace and rewrite [it] [..]

Yeah, the situation is complicated. We could try different approaches for each dependency too, and perhaps some of them will change their mind. Debian does (on purpose) make it quite high-cost to maintain forked packages, in the sense that we would have to argue our way through many layers of admins of different systems, to incentivise us to get patches accepted upstream.

When you have time, could you write up the details of the situation on your end? Something similar to the wiki page I posted earlier - or you could also just edit that directly, if you wish.


I also definitely want Sage in Debian, and don't think the "Debian moves too slowly" argument is valid anymore for Sage. It was a compelling argument in 2007, as mentioned elsewhere, but Sage is much more mature now. infinity0 -- thanks for your encouragement from Debian!!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: