Jeroen Demeyer: > On 2016-10-18 17:52, Ximin Luo wrote: >> One straw-man way to resolve this is to move the tests into a separate >> Debian package "sagemath-distribution". > > I still think that this is the real solution, also because it mimics what > Sage does: within the Sage-the-distribution build system, Sage-the-library > (sagelib) is just one of the many packages. > >> However, this makes the workflow very awkward for us, especially when it >> comes to distributing binary packages. Debian has automated build systems >> that build things on architectures that the developer doesn't have access >> to. We would have to build sage-library, upload it, wait for the automated >> systems to build it and distribute it, then if this is succesful on all >> architectures, only then can we upload sagemath-distribution to run the >> actual run-time tests. If any of these fail, we have to start the whole loop >> again. > > This really sounds like a Debian-specific problem. I don't understand why > Debian makes it so difficult to test a package on the buildbots. > >> if you guys ever convert sagelib into an spkg and have Sage-the-distribution >> download this as an external dependency (I see that #21507 goes in this >> direction), you will experience this pain yourselves. My guess is you will >> then very likely add an exception into Sage-the-distribution to use a local >> development copy of sagelib, to reduce the write-run-fix loop time. > > I don't think that Sage-the-distribution will ever treat sagelib exactly like > it does other packages. Even if it is a separate package on PyPI, I expect > development to remain essentially the same as today. >
Do you see the similarity between the Debian scenario and this future potential Sage scenario? That is why I mentioned those two together. You acknowledge that in the Sage scenario, Sage-the-distribution would have to treat sagelib specially, and not exactly like the other spkgs. But no other buildsystem/distribution has the equivalent concept - Debian does not have "special" packages where the buildbots say "OK we'll let you do [this workflow with sagelib<->fpylll]"; pip doesn't have this; etc etc. Nor do they have "whole-distribution" tests - tests are per-package, and are run inside the "build" of that package. This is a fundamental difference in approach to packaging/distribution. I think it's not possible (or reasonable) to expect one approach to fit inside the other - but we can work out a shared subset that we can both agree to. This shared subset would be to avoid creating dependency paths like the current fpylll+sagelib situation. It is working well for Debian and SageMath 7.3 so far. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
