> On 20/02/2015, at 06:54, Michael Orlitzky <mich...@orlitzky.com> wrote: > > 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.
There is a precedent. Jeroen has had pari 2.4 snapshot for a while before the release of 2.5. And yes it was madness on my side. For the whole time and some time afterward I had pari-2.4 snapshot in the overlay as a separate slot. It is effectively creating a sage-pari package and making sure that you have the whole stack using this package. If we go ahead with pari snapshot that’s what I will do this time. Not pari-2.8_prexxxxx it will be sage-pari-YYYYMMDD and a lot of patching. And as usual I will not complain and just bear it not to make waves. There is inherent conflict between developer wanting/needing the bleeding edge and the package maintainer that needs to see the overall stack and Jeroen should know from is experience with pari 2.4 will he was release manager. But he only cared about the set inside of sage and he doesn’t want to know what it is to care for a much larger stack. It is true that it is not is problem. But some of us would like to be given some consideration. François -- 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.
