Re: [sage-devel] Patching policy

2018-06-11 Thread Timo Kaufmann
To be clear I am not advocating to create a fork of every dependency. That would probably only worsen the problem (making it even easier to pull the "patch trigger" and harder to find the patches for distributions). -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Patching policy

2018-06-11 Thread Jeroen Demeyer
On 2018-06-08 13:05, Dima Pasechnik wrote: patches are not the best way to update things. VCSs are much better... Fair enough, that's a reasonable argument, although most patches actually don't need to be updated. For example, if the patch comes from upstream, there is no need to do

Re: [sage-devel] Patching policy

2018-06-08 Thread Matthias Koeppe
See also http://doc.sagemath.org/html/en/developer/packaging.html#how-to-maintain-a-set-of-patches On Friday, June 8, 2018 at 4:05:47 AM UTC-7, Dima Pasechnik wrote: > > > > On Friday, June 8, 2018 at 9:25:33 AM UTC+1, Jeroen Demeyer wrote: >> >> On 2018-06-08 07:47, Ralf Stephan wrote: >> >

Re: [sage-devel] Patching policy

2018-06-08 Thread Dima Pasechnik
On Friday, June 8, 2018 at 9:25:33 AM UTC+1, Jeroen Demeyer wrote: > > On 2018-06-08 07:47, Ralf Stephan wrote: > > It might be an idea to semi-automatize this, i.e., build a tool that > > takes a Sage version and creates forks of some packages A,B on github > > under sage/sage-A,

Re: [sage-devel] Patching policy

2018-06-08 Thread Ralf Stephan
On Friday, June 8, 2018 at 10:25:33 AM UTC+2, Jeroen Demeyer wrote: > > On 2018-06-08 07:47, Ralf Stephan wrote: > > It might be an idea to semi-automatize this, i.e., build a tool that > > takes a Sage version and creates forks of some packages A,B on github > > under sage/sage-A, sage/sage-B.

Re: [sage-devel] Patching policy

2018-06-08 Thread Jeroen Demeyer
On 2018-06-08 07:47, Ralf Stephan wrote: It might be an idea to semi-automatize this, i.e., build a tool that takes a Sage version and creates forks of some packages A,B on github under sage/sage-A, sage/sage-B. Which problem would that solve? -- You received this message because you are

Re: [sage-devel] Patching policy

2018-06-07 Thread Ralf Stephan
On Thursday, June 7, 2018 at 2:36:35 PM UTC+2, Timo Kaufmann wrote: > > In some cases where upstream has vanished and sage effectiely maintains > the project through patches anyways, it may be a better idea to just fork > the project. > It might be an idea to semi-automatize this, i.e., build a

Re: [sage-devel] Patching policy

2018-06-07 Thread Timo Kaufmann
2018-06-07 15:06 GMT+02:00 Jeroen Demeyer : > And I'm not saying there should be absolutely no patches, just that they >> should be the very last resort. >> > > I mostly agree with this, it's what I'm already doing. It just depends > where you put the borderline of "very last resort" and there we

Re: [sage-devel] Patching policy

2018-06-07 Thread Jeroen Demeyer
On 2018-06-07 14:36, Timo Kaufmann wrote: For what its worth, here is debians fix (self-labeled as "extra-hacky") for that issue: https://salsa.debian.org/science-team/sagemath/blob/master/debian/patches/dt-version-glpk-4.60-extra-hacky-fixes.patch That's not a fix at all. I could easily come

Re: [sage-devel] Patching policy

2018-06-07 Thread Timo Kaufmann
2018-06-07 14:16 GMT+02:00 Jeroen Demeyer : > On 2018-06-07 13:24, Timo Kaufmann wrote: > >> I don't really agree but even if that was the case, the PARI stackwarn >> patch could have been handled through filtering within sage instead >> (which I proposed in that ticket). >> > > You proposed

Re: [sage-devel] Patching policy

2018-06-07 Thread Jeroen Demeyer
On 2018-06-07 13:24, Timo Kaufmann wrote: I don't really agree but even if that was the case, the PARI stackwarn patch could have been handled through filtering within sage instead (which I proposed in that ticket). You proposed filtering *in the testsuite*. That comes back to my point about

Re: [sage-devel] Patching policy

2018-06-07 Thread Timo Kaufmann
2018-06-07 11:12 GMT+02:00 Jeroen Demeyer : > I think that your post is focusing too much on tests, as if the only > purpose of Sage is to pass its testsuite. It's actually the other way > around: the purpose of the testsuite is to ensure that Sage functions > correctly. Of course. But the

Re: [sage-devel] Patching policy

2018-06-07 Thread Jeroen Demeyer
I think that your post is focusing too much on tests, as if the only purpose of Sage is to pass its testsuite. It's actually the other way around: the purpose of the testsuite is to ensure that Sage functions correctly. By patching the testsuite to accept buggy output anyway, you're not really

[sage-devel] Patching policy

2018-06-06 Thread Timo Kaufmann
I have recently re-written the nixpkgs sage package to use system packages[1] (not merged yet). While doing that I noticed that while sage patches a lot of its dependencies (81 out of 276 packages have a `patches` folder). There are more or less 3 categories of patches: 1.