[Debian-science-sagemath] pari-sage or pari ?

[Ximin Luo]

Jeroen Demeyer:
> Most Sage devs are volunteers too, so we are in the same boat.
> 
> Anyway, to return back to the topic: I think that Sage would be happy to help with packaging for Debian (we did that before with Gentoo), but not if it negatively affects Sage itself.
> 

Sometimes Debian maintainers will accept extra patches for their packages, if you ask - usually based on some argument that it won't affect other packages in an unpredictable or negative way. And that's what we've been doing for Sage in Debian.

One decides their own definitions of "negative". Interoperating in a connected ecosystem of software involves making certain types of engineering tradeoffs. If you don't feel those tradeoffs are worth the benefits, that's your decision. Then the costs for interoperation are harder.

If you wanted to make it easier for us (and other OS distributions), you can generally put more emphasis on upstreaming your patches more quickly, add it to a policy or guideline document, and pressure people to do this before committing code that depends on patches.

For example, I don't understand why this patch [1] has not yet been accepted. All you have to do is write some unit tests. There are only ~10 tests in Sage that depend on the behaviour of this patch; the code should not have been committed to Sage unless this patch was already accepted to upstream. This should not "negatively impact" Sage other than waiting a few weeks. But we have nice VCSs and merge algorithms now to make this pretty painless.

(This particular patch might have a "really really good reason" - I can't decide that because I'm not a Sage developer - but really, for something this small, probably the reason is not as good as you think.)

X

[1] https://github.com/numpy/numpy/pull/6659

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git