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
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
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:
>> >
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,
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.
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
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
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
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
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
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
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
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
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.
14 matches
Mail list logo