Hi,
Le 19/02/2015 17:29, William Stein a écrit :
On Thu, Feb 19, 2015 at 11:24 AM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
On 2015-02-19 16:55, Michael Orlitzky wrote:
It's not incompatibility with Debian that's the problem. Having
dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
UTC-5" leads to madness.
Why madness?
It has been done before (#9343) and it worked just fine.
Waiting forever until PARI makes a new stable release, that's madness.
Bundling the git repo is a short-term solution that bones everyone else
(and possibly us, too, if upstream starts reverting commits)
If upstream reverts the occasional commit, we can deal with that. Stable
releases also remove/change functionality, so what's the difference?
A better
solution would be to work with them, settle on a set of commits that are
definitely going to stay, and make a release. Yes, it's more work *right
now*, but most good ideas are.
We can't tell PARI to make a new stable release for us, it just doesn't work
that way.
+1 to everything said by anybody who has been the Sage release
manager, hence has a better understanding of the constraints.
The constraints are the same for each software project. Please, don't
hesitate to depend on dev versions of pari, but then make sure you're
compatible with the next release (ie: if upstream changes break sage,
don't commit away the changes, but make sage move to be compatible).
And if there is no upstream release in sight and you still want to go
forth : make a special release, stating clearly that it's not upstream.
If you depend on a foo 3.14 which isn't upstream, that's a problem for
serious distributions, since they won't lie. Make your package a sagefoo
3.14, and now there's something to package.
Sage's libgap and cddlib are problems : they correspond to upstreams,
but they are forks : packaging them would be lying to the users. Rename
them to libsagegap and sagecddlib, and everything changes : sage isn't
lying about its deps, debian isn't lying about what it packages.
I want to remind people that the goal of Sage is to be a competitor to
Mathematica, Matlab, Magma and Maple. This is a very high bar, and it
requires doing things that are much harder than what is possible
within the framework of constraints of waiting for stable versions of
all dependencies to catch up, etc.
If you look at :
https://people.debian.org/~thansen/debian-sage-dev-status.html
then you'll see that sage isn't on the bleeding edge as you think it is.
Yes, debian stable is slow, very slow -- many would say: much too slow.
But testing is quite fast already, and unstable and experimental move
very fast. Oh, by the way, as I write it, the page above still says we
have flint 2.4.4 -- in fact, flint 2.4.5 is in unstable : another blue line.
Saying that SageMath has incredible constraints that no other software
project has, that it's so unbelievably fast that its deps can't keep up,
that it leaves a fire trail before it everywhere it goes... it's just
boasting!
Sage-the-software is a normal project, which would probably be able to
move faster if it weren't glued to sage-the-distribution.
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.
