> 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
> 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.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.