Le 19/02/2015 15:21, Jeroen Demeyer a écrit :
On 2015-02-19 12:56, Julien Puydt wrote:
Well, examples exist where poor choices have been made which make(made)
it harder for other projects.
From the top of my head :
(1) ECL was configured to disable SIGCHLD... by patching it! I proposed
a two-line patch which did it programmatically from sage's code.
(2) PARI/GP is configured using a gprc... shipped by the spkg -- ticket
#17796 is about pushing that in sage's code.
Sure, these are two examples where improvement is possible. Sage
developers are not perfect and there are indeed many things in Sage
which are less than optimal.
I never said that we shouldn't improve where we can. Indeed, (1) has
been fixed and I am willing to review (2). However, don't let these two
rather trivial issues distract you from the bigger issue of package
dependencies.
All distributions have thousands of packages, and deps are not a big
issue. Sage-the-distribution has about a hundred, and it's a big issue.
A software package which claims it depends on a series of others with
precise version requirements is ok : if the requirements aren't met, it
can't be shipped, but there's a list of things to ship before.
Everything is clear, honest.
A software package which claims it depends on a series of others with
precise version requirements, but when you look a little more closely,
some of them are not really what upstream distributes, there are patches
here and there... that is bad, and not something a serious distribution
can accept.
I don't think software was ever delayed for debian.
If people are against #16997 because it's not compatible with Debian,
then Debian is *already* slowing down Sage.
If sage claims it needs a version debian doesn't have, that's not a
problem. But if upstream 2.8 comes out and it turns out sage's pari
isn't compatible with it, then it's bad!
Depending on development versions not packagable in serious
distributions isn't a problem as long as it's a transient property! Most
software project are like this... but they strive to make releases now
and then where they do depend only on stable releases of their deps.
In conclusion: nobody will vote against #16997, as it's normal practice.
But when pari 2.8 comes out, that will be a severe bug if the new
release can't seamlessly replace the snapshot.
Snark on #sagemath
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
