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
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
(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.
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 firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.