refine definition of variable SAGE_NEED_SYSTEM_PACKAGES in m4/sage_spkg_collect.m4

[slabbe]

The goal of this ticket is to improve the suggestions about which packages should be installed on the system provided at the end of the ./configure. Often, it suggests to install a package which is already installed on the system. Let me explain it with an example based on the package sympow.

On Ubuntu 18.04, the version of sympow installed on the system with sudo apt install sympow is:

$ sudo apt-get update
$ sudo apt-get install sympow
$ sympow -version
1.023 RELEASE (Debian 1.023-8)

As understood in #30633, that version of sympow has an issue which is fixed upstream in version 2.023.6 available as a sage spkg. Therefore, sage will not use the sympow provided by the system anymore if some test of sympow fails, as shown below:

$ grep sympow config.log
## Checking whether SageMath should install SPKG sympow... ##
configure:32515: checking for sympow
configure:32533: found /usr/bin/sympow
configure:32545: result: /usr/bin/sympow
configure:32558: checking whether sympow works well (cf. :trac:30147 and :trac:30633)
configure:32565: result: no; cannot use system sympow
configure:32592: no suitable system package found for SPKG sympow
configure:38102: result: sympow-2.023.6:                              no suitable system package; will be installed as an SPKG

What I dislike is the suggestion that follows:

configure:39587: notice: the following SPKGs did not find equivalent system packages: _recommended boost ... sympow tox
configure:39587: checking for the package system in use
configure:39590: result: debian
configure:39599: hint: installing the following system packages is recommended and may avoid building some of the above SPKGs from source:
configure:39601:   $ sudo apt-get update 
  $ sudo apt-get install ...  sympow

It suggests me to install sympow! But it is already installed!

The reason for this bug is the definition of the variable SAGE_NEED_SYSTEM_PACKAGES in the file m4/sage_spkg_collect.m4 which is too inclusive in my opinion.

Let us start with the file build/pkgs/sympow/spkg-configure.m4 where the version of sympow (if available) is checked:

$ cat build/pkgs/sympow/spkg-configure.m4 
SAGE_SPKG_CONFIGURE([sympow], [
   AC_PATH_PROG([SYMPOW], [sympow])
   AS_IF([test -z "$ac_cv_path_SYMPOW"], [sage_spkg_install_sympow=yes
      ], [
      AC_MSG_CHECKING([whether sympow works well (cf. :trac:30147)])
      sympow_rank_test=`echo "@<:@1,-1,0,-79,289@:>@" | sympow -analrank | grep ^"Analytic Rank is 4"`
      AS_IF([test x"$sympow_rank_test" = x], [
          AC_MSG_RESULT([no; cannot use system sympow])
          sage_spkg_install_sympow=yes
          ], [
          AC_MSG_RESULT([yes; use system sympow])
      ])
   ])
])

I am not so familiar with the m4 language, but as I understand the above the result is two-fold :

• yes; use system sympow or
• no; cannot use system sympow.

Instead, what it should return is three-fold:

• yes; use system sympow
• no; cannot find system sympow.
• no; system sympow was found (version 1.023) but failed check requirements.

Notice that there are already two level of AS_IF in the above build/pkgs/sympow/spkg-configure.m4, so it should not be hard to fix.

After that, in the file m4/sage_spkg_collect.m4 the line

     AS_VAR_APPEND([SAGE_NEED_SYSTEM_PACKAGES], [" $SPKG_NAME"])

which appends the package name to the list SAGE_NEED_SYSTEM_PACKAGES when the result obtained from build/pkgs/sympow/spkg-configure.m4 is no should be fixed so that it appends it to the list only if the answer is no; cannot find system sympow.

Thus, the suggestions provided at the end of configure will be better. Moreover, the suggestions provided at the end could also give the list of packages that were installed but not suitable. That may need to create a new variable. I think that NOT_FOUND_SYSTEM_PACKAGES and FOUND_BUT_DECLINED_SYSTEM_PACKAGES would be good names for replacing the SAGE_NEED_SYSTEM_PACKAGES variable.

I am sorry I don't feel confident to edit the involved m4 files. I let this for others hoping they will agree with the above.

[slelievre]

See an attempt in #30624, which I need to finalize.

[slelievre]

I wrote too fast. What you suggest is different.

It can be considered as part of #29146 and related to #29586.

[mkoeppe]

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.