Hi, we're trying to package Sage 7.4 for Debian and are running into a difficulty. This will affect not just Debian, but all buildsystems / distributions that want to (1) run tests at build-time, before installation and (2) don't allow extra installations or network access *during* the build of a single component. This is the vast majority of buildsystems. Here, a run-time dependency is a test-time dependency is a build-time dependency (in the general case).
Notably, Sage's own buildsystem does not have restrictions (1) and (2) - one can build sagelib, build fpylll, install fpylll, then test sagelib. However, most buildsystems do not do this and/or can't do this, for various reasons. I don't want to get into a detailed discussion about whether these are good or bad reasons, I just want to point out this is reality today. So in effect, the situation with Sage 7.4 is that there will a circular dependency when trying to package it in most distributions, even if this circular dependency does not exist in Sage-the-distribution's own Makefiles. I am not arguing against post-install tests. Post-install tests are a good thing, and Debian is encouraging more of them these days. But we still *also* want pre-install tests. The reason is that these have a much smaller write-run-fix development feedback loop, which are easier to work with - one doesn't have to mentally context switch so much. Post-install tests are good as a "final check", but they are awkward to work with as the primary check, at least for Debian and many other distros / build systems. We can do "pre-install tests" with Sage 7.3, by doing a "dummy install" using Sage's Makefiles, running the tests here, then installing them to the "real location". (This requires some patching, but we have achieved this already and it works.) However with Sage 7.4 this is not possible, due to the fpylll situation. Packages in Debian (and most other buildsystems) are built and tested as distinct units, we can't build A, install A, build B, install B, then test A. One straw-man way to resolve this is to move the tests into a separate Debian package "sagemath-distribution". 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. Since 99% of the tests in Sage-the-distribution are actually for code that belongs in Sage-the-libary (and the other 1% is for SageNB), it is much easier to run the tests as part of the Sage-the-library Debian package - one doesn't have to mentally context-switch so much. Yes, metapackages also exist in Debian and other distros, but these packages don't have their own tests; their dependencies test themselves, and the metapackage "does" nothing. Let me further assure you that this is not a problem unique to Debian: 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. Another problem is that, if in the future someone creates a new project X, that depends on fpylll-without-Sage, and Sage later wants to use project X, you will have to build and install two flavours of fpylll. The previous straw-man resolution is totally useless here - it is a straw-man workaround for distros, but this problem directly affects Sage itself regardless of what distros do. So, a much better alternative of resolving the fpylll issue would be to not have fpylll build-depend on Sage. (1) I can see that it's possible to build fpylll without Sage, it will just have a different API. Could we patch Sage-the-library to use fpylll-without-Sage, then have Sage itself convert the non-Sage integers into Sage integers? (2) In the long run, one can think about splitting out sage.rings.integers (and related things) into a small library "sage-types" or something like that. Then sagelib and fpylll can depend on this, and there would be no circular dependency, even when Debian or other distros try to build it. So, what are the problems with (1)? If there are no problems, could we patch this *before* Sage 7.4 is released? I would be happy to write the patch myself, but guidance on where to start would also be much appreciated. 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.
