Hi,
Le 20/02/2015 01:22, William Stein a écrit :
On Thu, Feb 19, 2015 at 12:51 PM, Francesco Biscani
<bluesca...@gmail.com> wrote:
On 19 February 2015 at 18:05, Julien Puydt <julien.pu...@laposte.net> wrote:
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.
This is something I have failed to understand so far. What is it that makes
Sage require such special handling of dependencies (i.e., package everything
in one monolithic blob and with ad-hoc patching)?
See http://wiki.sagemath.org/faq/bigsagerant for another past Sage
release manager's rant on this topic from long ago (maybe 2008?).
"== Wouldn't it be way better if Sage did not ship as a gigantic bundle? ==
This has been discussed over and over again and it plainly doesn't
work. The Sage in Debian does not pass doctests, not even close. In
general the combinatorial explosion of configurations to debug is way
too large and it is next to impossible to find any distribution where
the version numbers even remotely match. We updated to GAP 4.4.12 in
Sage 3.3 and the doctests involving GAP will in certain files be
broken with any previous GAP release. If you used the Debian packages
for Singular Sage won't work since we patch NTL and when those NTL
libs come in conflict either Sage doesn't compile or Singular blows
up. I can go on and on and on about similar issues and that is only
the stuff I know about right on top of my head. I have never taken the
time to go out and do dumb things to break Sage :)
In the near future we plan to upgrade to a svn release of the
development version of pari and then closely track it as bugs we
report are often only fixed in pari-2.4.3svn. There is *no* way any
distribution can track this without potentially breaking other code
dependent on pari and you will be royally screwed if you want to use
pari 2.3.4 in Sage (the stable release at this point) since Sage won't
even build. We will fix all in tree code that gets broken with the new
pari-svn and push it back upstream, but until that shows up in a
distribution we will long have shipped Sage 4.0.
The way we do it is the only way and I have doubts that any
distribution packaged Sage will even be able to keep up with the
official release given that I (=Michael Abshoff) spend working full
time as the Sage
release manager :)"
Yes, the same drama as usual :
- sage is incredibly complex
=> FACTS: all distributions are orders of magnitude more complex
- sage has extremely special needs because it's mathematics
=> FACTS: all software has special needs, and being about
mathematics doesn't make it worse -- just put unit tests, we'll run them
after the build and no package failing them will get out the door (eclib
and flint come to mind as example of good-behaving mathematics software
packages)
- sage is on the bleeding edge
=> FACTS: there are quite a few packages where sage can barely keep
up with upstream -- see
https://people.debian.org/~thansen/debian-sage-dev-status.html
- sage needs to be able to use dev versions
=> FACTS: you can, and please do! But :
(1) label them clearly as not upstream versions, and make sure you
stay compatible with upstream dev versions so the next upstream stable
will be a drop-in replacement to your stuff (pari)
(2) if you (plan to) stay away from upstream long, then actually fork
upstream with a clear name so we can package in a co-installable form
(libgap and cddlib)
- debian's sage sucks
=> FACTS: it did, and now there is none. When there will be, no
package won't get out of the door if it doesn't pass doctests. Of
course, some of them will be disabled, like those checking paths, or
checking that the available color maps in matplotlib is some short list,
but that shouldn't matter.
There's a lot of complex software around with long dependency chains
(Firefox, Chrome, KDE, GNOME, OpenOffice, ...) and it seems like most Linux
distributions are able to deal with this, without too many issues, via
system-wide libraries.
Those are a different domain of software engineering. Mathematics
software is fundamentally different than word processing, graphical
desktop, and web browser software. It doesn't matter much if a line
in a UI is off by one pixel. In mathematics, being off by 1 can
result in major bugs all over Sage.
Off by one can be a crash in word processing, graphical desktop, web
browser software and pretty much anything else : it does matter
everywhere. Packagers routinely run "make check" in their build scripts
so they don't ship clearly broken software.
The Sage distribution model, which has frequently been attacked every
single year for nearly a decade, is one of the most important reasons
for Sage's success.
Is it a good reason to push third-party packagers around like
second-class citizens? Let me quote François Bissey :
"But some of us would like to be given some consideration."
That said, if somebody had the energy to make and maintain a
branch/fork of Sage that could easily integrate with Linux distros,
more power to them. I'd be happy to host it, point to it on the sage
website, etc. If I had infinite resources (money) I would definitely
hire somebody to create and maintain such a thing. It wouldn't even
be a question. The problem is that right now we have *extremely*
limited resources and have to make choices.
You can't hire someone for each distribution, and nobody asked anything
about it. But if sage developers could realize that there is
sage-the-software and sage-the-distribution, that would definitely help.
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.
