RFC: demote giac to optional

[Michael Orlitzky]

Hi, I've separated sage.libs.giac into its own package, and would like
to downgrade giac to optional at the same time the new package is
added, cf.

* https://github.com/sagemath/sagemath-giac
* https://github.com/sagemath/sage/pull/39376

tl;dr now is the time to object.

The reason for this, and the reason why I am working on this in the
first place, is because giac no longer builds and runs reliably. It
fails:

* On riscv systems
* On systems with a hardened glibcxx
* On macos M2 (according to Volker)
* With gcc-15, due out in the next few months

There is "inertia" with respect to getting any of these fixed. For
myself, the list above now covers 100% of the machines that I use on a
daily basis. And since libgiac is linked with sage, having giac as an
unconditional dependency makes it very difficult to use sage.
(Thankfully, giac is already optional when using meson to build sage.)

On any of those systems, we need a way to disable giac and the
sage.libs.giac integration. That's the motivation for the new
package/PR. The remaining question is, do we leave giac and
sagemath-giac as standard, and tell everyone who experiences problems
to disable it? (We would also need a mechanism to disable it.) Or do
we make it optional, and let the people who use it enable it?

Currently the PR makes it optional. I think there are some good
arguments for this:

1. It used to be optional a few years ago. We moved it into sagelib
to avoid a circular dependency between sagelib -> sagemath-giac
-> sagelib, but now there is no circular dependency. All integration
backends are "optional" because we run through the list and skip
any that don't return a result.

2. It's already optional when you use meson to build sagelib, so this
makes the two approaches consistent.

3. We don't lose any killer features, only a few clever integrals
that maxima/sympy can't solve.

4. It makes us look bad when things fail and we have to tell people
on the mailing list how to work around it.

5. Build time goes down.

6. Sage is less likely to break during "apt-get upgrade" or
equivalent.

7. If you want it back, "make sagemath_giac" or ./configure
--enable-sagemath_giac only take a minute.

On the other hand the biggest downside is that if someone was using
libgiac directly in their own code or was relying on it for some
indefinite integrals, then they are probably going to be confused when
it isn't there in the next release. It's easy to fix, but they're
going to have to ask what happened first, and obviously that hits (4)
above too. FWIW I would write this all up in the release notes.

[Dima Pasechnik]

Yes, by all means, please make giac optional.

[John H Palmieri]

For what it's worth, on my macos M2 machine, giac builds but it fails its test suite:

[giac-1.9.0.15p0] [spkg-check] PASS: chk_partfrac
[giac-1.9.0.15p0] [spkg-check] PASS: chk_factor
[giac-1.9.0.15p0] [spkg-check] PASS: chk_integrate
[giac-1.9.0.15p0] [spkg-check] PASS: chk_geo
[giac-1.9.0.15p0] [spkg-check] FAIL: chk_fhan2
[giac-1.9.0.15p0] [spkg-check] PASS: chk_cas
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan3
[giac-1.9.0.15p0] [spkg-check] FAIL: chk_fhan4
[giac-1.9.0.15p0] [spkg-check] PASS: chk_morley_demo
[giac-1.9.0.15p0] [spkg-check] PASS: chk_xavier
[giac-1.9.0.15p0] [spkg-check] FAIL: chk_fhan6
[giac-1.9.0.15p0] [spkg-check] PASS: chk_limit
[giac-1.9.0.15p0] [spkg-check] FAIL: chk_fhan8
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan5
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan0
[giac-1.9.0.15p0] [spkg-check] PASS: chk_normalize
[giac-1.9.0.15p0] [spkg-check] FAIL: chk_fhan13
[giac-1.9.0.15p0] [spkg-check] FAIL: chk_fhan12
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan14
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan1
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan15
[giac-1.9.0.15p0] [spkg-check] FAIL: chk_fhan11
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan17
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan16
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan20
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan19
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan21
[giac-1.9.0.15p0] [spkg-check] FAIL: chk_fhan9
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan18
[giac-1.9.0.15p0] [spkg-check] PASS: chk_fhan7
[giac-1.9.0.15p0] [spkg-check] ============================================================================
[giac-1.9.0.15p0] [spkg-check] Testsuite summary for giac 1.9.0
[giac-1.9.0.15p0] [spkg-check] ============================================================================
[giac-1.9.0.15p0] [spkg-check] # TOTAL: 30
[giac-1.9.0.15p0] [spkg-check] # PASS:  22
[giac-1.9.0.15p0] [spkg-check] # SKIP:  0
[giac-1.9.0.15p0] [spkg-check] # XFAIL: 0
[giac-1.9.0.15p0] [spkg-check] # FAIL:  8
[giac-1.9.0.15p0] [spkg-check] # XPASS: 0
[giac-1.9.0.15p0] [spkg-check] # ERROR: 0
[giac-1.9.0.15p0] [spkg-check] ===============================

I don't know what the failed tests are.

I've also been seeing giac-related doctest failures on OS X for the last two years: https://github.com/sagemath/sage/issues/35646

[Dima Pasechnik]

On Thu, Feb 20, 2025 at 1:25 PM John H Palmieri <jhpalm...@gmail.com> wrote:
>
> For what it's worth, on my macos M2 machine, giac builds but it fails its test suite:

Given that macOS is a supported platform, one has to have jolly good
reasons for keeping giac standard - while it fails self-tests.
If Volker would be merging a giac update and see these tests failing,
he'd not proceed with the merge, right, Volker?

Dima

> --
> 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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/1b99f496-bdfd-4b25-b165-ea78e7f4685bn%40googlegroups.com.

[Vincent Delecroix]

I think it would be more productive to make two PRs: one for making
the package which is likely to create a consensus and one for demoting
to optional which might be controversial.

One important argument against optional packages is that they are
rarely available in linux system pacakges (on a system sage). This
creates a handicap for most of our linux users who whishes to use
(some features of) giac. But having that said, if giac does not build
on supported platform this is a stronger argument in favor to the move
to optional.

Best
Vincent

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1Bd9uR49ZGQHbrFJR4MRE6J5irUi_khL1tW8r4fAtc9A%40mail.gmail.com.

[Volker Braun]

Giac has always segfaulted on my M2 Mac Mini buildbot, so it never got *worse* when merging a ticket. As far as I know it only works on Intel macs (endangered species as they are).

For the record, +1 to making giac optional. 

[Michael Orlitzky]

On 2025-02-21 15:45:17, Vincent Delecroix wrote:
> I think it would be more productive to make two PRs: one for making
> the package which is likely to create a consensus and one for demoting
> to optional which might be controversial.

While generally a good idea, in this case it would create more work
because we would need an interim solution to disable (the otherwise
standard) giac on the platforms where it is doomed. The second PR
would then have to undo that solution.

I'll do it if I have to, but (knock on wood) no one has objected yet
and I have my fingers crossed that I can omit the intermediate step.

[dim...@gmail.com]

On Fri, Feb 21, 2025 at 03:45:17PM +0100, Vincent Delecroix wrote:
> I think it would be more productive to make two PRs: one for making
> the package which is likely to create a consensus and one for demoting
> to optional which might be controversial.

The package is already done, it's in https://github.com/sagemath/sagemath-giac/

>
> One important argument against optional packages is that they are
> rarely available in linux system pacakges (on a system sage). This
> creates a handicap for most of our linux users who whishes to use
> (some features of) giac.

I don't understand - are you talking about Sage
installed from source? If so, then enabling an optional package is ver
easy. (./configire --enable-giac)

How does the lack of a system-wide giac matter here?

> But having that said, if giac does not build
> on supported platform this is a stronger argument in favor to the move
> to optional.

(lib)giac is fragile in very many ways, and its importance to Sage is
limited. Giac package is very hard to maintain, as it continues to
violate all sorts of rules and customs, such as not having a git
repository on its own, messing library versioning, messing tarballs
(updating them without changing versions), etc. Cf. e.g.
https://github.com/sagemath/sage/issues/38985
https://github.com/sagemath/sage/issues/38668
https://github.com/sagemath/sage/issues/33665
and many more

Dima

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CAGEwAA%3Dstph_dxmMijnJC7W6rmEcpFFxMiT4jEpvH0RW%3D_NayQ%40mail.gmail.com.

[parisse]

Don't worry, I won't try to convince sage maintainers that they should not downgrade giac, it seems we do have too incompatible views and probably not the same target audience (which may explain that some people here believe giac is about solving a few more integrals than maxima or sympy). However, I'd like to correct some facts:

1/ there are prebuilt universal binaries of Giac/Xcas for Mac (Intel/arm64). More information here:

https://www-fourier.univ-grenoble-alpes.fr/~parisse/install_en.html#osx

2/ the giac distribution tarballs once published in my debian source repository, are not modified after publication since many years.

3/ I did not try the latest version of gcc, if giac does not build, then of course I'll make the required changes.

Let me conclude by a French sentence: "Quand on veut tuer son chien, on dit qu'il a la rage"

Bye!