On 02/19/2015 11:24 AM, Jeroen Demeyer 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?
If you try to have sage coexist with *any* other piece of software on the system, it's going to conflict. Every other package in the ecosystem depends on something like >=pari-1.0 and <pari-2.0. But sage requires EXACTLY commit (say) 02a793ab4325. First of all, nobody knows how to resolve that (is 02a793ab4325 bigger than 1.0?). Second, it restricts the solution space so much that an installation plan will be impossible once a few packages are involved. Dependency resolution is usually a set of overlapping intervals. If the intersection is nonempty, some version works and you install that. If not, you're stuck. Depending on exactly one specific commit is intersecting with a point. Unless you're *very* lucky, you're going to wind up with an impossible constraint. > > It has been done before (#9343) and it worked just fine. > This presupposes that the status quo is not madness. My sage builds work for about two weeks before some invisible dependency update breaks them. There's a line in sage beyond which we just don't care about dependencies. We ship gcc, some utilities, and a bunch of math software. But we don't ship e.g. glibc. Guess what happens when I rebuild glibc on my machine? Sage breaks. What happens if I rebuild gd on my machine? Sage breaks. What happens if I rebuild dvipng on my machine? Sage breaks. I no longer use sage for my day-to-day work, but when I was and I had to e.g. give a presentation, it was infuriating to find sage broken AGAIN at 8am. Sage-on-gentoo fixes this, but not if I want to submit patches, because the official sage has a gigabyte of junk bundled with it and whoever reviews my patch will be using that. Nobody wants to bundle *everything* because that'd be crazy, right? But unless we do, bundling *anything* is going to lead to breakage. If we were forced to fix the regular breakage by bundling everything, we'd all agree that it was madness to maintain an entire distro. It's too much work and time that would be better spent writing math software. > We can't tell PARI to make a new stable release for us, it just doesn't > work that way. We can't make them, but we can ask nicely. Especially if we're willing to help. If they're like every other project on Earth, their limiting factor is manpower. There are alternatives, anyway. If the new pari just fixes some minor bug, who cares. We can say "this is fixed upstream" and if users want to upgrade their pari to some bleeding-edge commit, so be it. If the change is big, we should probably wait for a full release anyway to make sure we're working against the real, eventual API. We don't need to be responsible for every line of code that we depend on at any level. If it comes down to it, we could always fork pari and make a release. But we have to call it sage-pari or something else; otherwise pretending to be pari is going to cause problems with other packages that expect the real pari. -- 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.
