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 

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.


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

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.

Reply via email to