As far as I'm aware, everyone's current solution to packaging sage is to more or less completely ignore its own build system and do everything manually in whatever specification format your package manager uses. You will need to make sure it keeps working once the dependencies change. The test suite is pretty brittle, but invaluable. It can be done, but you should be aware that its pretty labor intensive.
Timo Am Sonntag, 10. Mai 2020 15:02:24 UTC+2 schrieb Thierry Thomas: > > Hello, > > TL;TR: Packagers, how do you deal with Sage to package it for your Linux > distribution (or *BSD system)? > > Details: > > Sage has been ported to FreeBSD many years ago (4.8), but now the port > is lagging and no more packages are built; I'm trying to fix it. > > Problem: on FreeBSD, packages are built (by a porter or in the > compilation farm) as a regular user, and installed in a staging > directory (DESTDIR); then the package is installed as root in the final > $PREFIX (ldconfig and so on are executed). > > The naming may differ, but many packaging systems have a similar > mechanism. > > But Sage cannot be built with this method: the global install target is > a no-op, and every sub-package is built and installed during the build > target, under $SAGE_LOCAL, and everything is built relatively to this > directory. If you try to move the resulting bits to another directory, > it becomes unusable. > > $SAGE_DESTDIR is handled, but does not solve this problem. > > A first way to deal with it is to use as many system packages as > possible (see #27330): Sage´s libraries built around a system package > are safe. > > For example, with the stock sage-9.1.rc3, when setting SAGE_LOCAL to my > staging directory, these errors are emitted for cvxopt: > > Error: 'lib/python3.7/site-packages/cvxopt/umfpack.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/base.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/amd.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/misc_solvers.so' is referring > to /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/blas.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/gsl.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/cholmod.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/glpk.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/lapack.so' is referring to > /usr/ports/math/sage/work/stage > Error: > 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_sdp_backend.so' > is referring to /usr/ports/math/sage/work/stage > Error: > 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_backend.so' is > referring to /usr/ports/math/sage/work/stage > > When using cvxopt from a system package (see #29665), these errors are > resolved. Unfortunately, even if the proposed method seems OK from my > packager´s POV, it seems that this is not the way to go: see #29023. > > Several interesting propositions exist in #29133 (#21566), and things > like #29653 are also helping, but these are middle or long term goals. > > And so my initial question: how do you package the actual releases? (9.0 > or 9.1) > > Many thanks for reading and for your feedback! > -- > Th. Thomas. > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/44cee254-250c-4a69-ad34-7247f1535e50%40googlegroups.com.
