Change Details

math/sage, also known as SageMath is a very important application for people working in mathematics or sciences. Unfortunately, this must-have is also a nightmare for packagers, and ATM the FreeBSD port is lagging and broken. This patch is a work-in-progress to try to fix it. /!\ This is just a WIP! Not [yet] committable at this point, and any help is welcome! This is a kind of meta-application, which builds as many math-related packages as possible to give them a common interface, and all these sub-packages are bundled. Upstream knows about this problem, and a ticket has been opened to "use as many system packages as possible": see #27330 at <https://trac.sagemath.org/ticket/27330>. But this is a long task, and a lot of packages are still bundled and built by Sage, and some of them do not respect DESTDIR (i.e. STAGEDIR). The hereunder patch allow to build everything, but several objects are referring to the staging directory. E.g.: Error: 'lib/liblinbox.so.0.0.0' is referring to /usr/ports/math/sage/work/stage Every sub-package can be patched, e.g. see files/psutil__arch__bsd__freebsd_socks.c.patch, but this would be a time consuming task. Maybe someone™ could have an idea to fix this globally? Another related problem is the installation directory. The current port installed everything under ${PREFIX}/${PORTNAME}-${PORTVERSION}. If we keep this, every installed object should know about this directory to find its related objects. If we try to install it directly under ${PREFIX}, it would create a lot of conflicts: a possible solution would be to remove these potential conflicts from the staging directory and use the external dependencies, hoping they have been built with similar options and compatible.

math/sage, also known as SageMath is a very important application for people working in mathematics or sciences. Unfortunately, this must-have is also a nightmare for packagers, and ATM the FreeBSD port is lagging and broken. This patch fixes it and upgrades it to the latest stable version (9.1). This is a kind of meta-application, which builds as many math-related packages as possible to give them a common interface, and all these sub-packages are bundled. Upstream knows about this problem, and a ticket has been opened to "use as many system packages as possible": see #27330 at <https://trac.sagemath.org/ticket/27330>. The proposed patch uses system packages from this list, completed with others which are not stage-clean when bundled, and others common ports to avoid as many conflicts as possible.

math/sage, also known as SageMath is a very important application for people working in mathematics or sciences. Unfortunately, this must-have is also a nightmare for packagers, and ATM the FreeBSD port is lagging and broken. This patch is a work-in-progress to try to fix itfixes it and upgrades it to the latest stable version (9.1). /!\ This is just a WIP! Not [yet] committable at this point, and any help is welcome! This is a kind of meta-application, which builds as many math-related packages as possible to give them a common interface, and all these sub-packages are bundled. Upstream knows about this problem, and a ticket has been opened to "use as many system packages as possible": see #27330 at <https://trac.sagemath.org/ticket/27330>. But this is a long task, and a lot of packages are still bundled and built by Sage, and some of them do not respect DESTDIR (i.e. STAGEDIR). The hereunder patch allow to build everything, but several objects are referring to the staging directory. E.g.: Error: 'lib/liblinbox.so.0.0.0' is referring to /usr/ports/math/sage/work/stage Every sub-package can be patched, e.g. see files/psutil__arch__bsd__freebsd_socks.c.patch, but this would be a time consuming task. Maybe someone™ could have an idea to fix this globally? Another related problem is the installation directory. The current port installed everything under ${PREFIX}/${PORTNAME}-${PORTVERSION}. If we keep this, every installed object should know about this directory to find its related objects. If we try to install it directly under ${PREFIX}The proposed patch uses system packages from this list, it would create a lot of conflicts: a possible solution would be to remove these potential conflicts from the staging directory and use the external dependenciescompleted with others which are not stage-clean when bundled, hoping they have been built with similar options and compatand others common ports to avoid as many conflicts as possible.