Reduce outdated gdb and valgrind packages to dummy script packages

[mkoeppe]

These are devtools, not needed for building.

Last update to gdb was made in 2018

Last update to valgrind was made in 2019

CC: @dimpase @jhpalmieri @orlitzky

Component: packages: experimental

Issue created by migration from https://trac.sagemath.org/ticket/30158

[mkoeppe]

Description changed:

--- 
+++ 
@@ -4,3 +4,5 @@
 https://github.com/mkoeppe/sage/runs/876312037
 
 
+https://ftp.gnu.org/gnu/gdb/
+

[dimpase]

comment:2

indeed, looks like makeinfo is missing;

can we just add makeinfo to the list of reqs on Linux (typically, it's texinfo, at least on debian/ubuntu package)

alternatively modify spkg-install to configure without makeinfo.

[mkoeppe]

comment:4

Sage development has entered the release candidate phase for 9.3. Setting a new milestone for this ticket based on a cursory review of ticket status, priority, and last modification date.

[mkoeppe]

Description changed:

--- 
+++ 
@@ -1,8 +1,6 @@
-We should ship a version that matches the shipped gcc package, for use in portability testing on system that we support.
+These are devtools, not needed for building.
 
-Currently we have gdb 8.2, and installation fails at least on `ubuntu-xenial`... perhaps only because of missing `makeinfo`?
-https://github.com/mkoeppe/sage/runs/876312037
+Last update to `gdb` was made in 2018
 
+Last update to `valgrind` was made in 2019
 
-https://ftp.gnu.org/gnu/gdb/
-

[jhpalmieri]

comment:9

Rather than dummy packages, or maybe in addition, would it make sense to put the relevant scripts in their own package? Or just document how to replicate their effects in the Developer's Guide, as I think @orlitzky suggested on sage-devel?

[mkoeppe]

comment:10

These packages don't supply the scripts; they are equivalent to any system installation of gdb or valgrind.

One thing that our python3 spkg does do is install some .supp files that come from the Python source distribution. Distribution packaging MIGHT install them too for use with system-packaged valgrind, but I am not sure how widespread that is.

So it could make sense to vendor python3's supp files as part of #33074.

[orlitzky]

comment:11

What benefit would we get from script packages opposed to removal?

I think the scripts can go, but not before we add some docs. There are a few critical tricks one needs to know:

• Entering a sage-shell
• Passing -i to sage-ipython
• The use of both python's and sage's suppression files
• Setting PYTHONMALLOC=malloc in the environment
• Ensuring that your glibc has debug symbols available

The python3 suppression rules generally won't be installed, but instead of vendoring them for the zero people that currently use this, we could probably just link to the rules file in the upstream repo. This is a process that's heavy on manual intervention anyway.

[jhpalmieri]

comment:12

Replying to @mkoeppe:

These packages don't supply the scripts; they are equivalent to any system installation of gdb or valgrind.

Sorry, I wasn't very clear. By "maybe in addition," I was asking if there should be a new package that supplies the scripts, valgrind-sage-support or whatever. The point is to remove those rarely scripts from src/bin unless the user specifically requests them.

One thing that our python3 spkg does do is install some .supp files that come from the Python source distribution. Distribution packaging MIGHT install them too for use with system-packaged valgrind, but I am not sure how widespread that is.

So it could make sense to vendor python3's supp files as part of #33074.

I don't know how any of this works. If someone uses a system Python without .supp files, can they use Sage-distributed .supp files instead? For what it's worth, homebrew doesn't seem to provide these:

% find /usr/local -name "*.supp" -print 
find: /usr/local/mysql-8.0.23-macos10.15-x86_64/keyring: Permission denied
find: /usr/local/mysql-8.0.23-macos10.15-x86_64/data: Permission denied
/usr/local/Cellar/glib/2.70.3/share/glib-2.0/valgrind/glib.supp

find /System/Library/Frameworks/Python.framework -name "*.supp" -print also returns nothing, although I don't know if that's the right place to look for .supp files for the default OS X Python installation.

Anyway, if it is possible to mix .supp files for different versions of Python, or if we can create new ones using whatever Python is being used by Sage, that could be part of the same valgrind support package.

[jhpalmieri]

comment:13

Regarding this I tend to agree with @orlitzky. Unlike some aspects of Sage, this is something that will only be used by people who know what they're doing, and they should be able to handle reading some docs to do it. Other parts of Sage must be accessible to math students and math researchers and other computer neophytes, but not valgrind.

[mkoeppe]

comment:14

Replying to @orlitzky:

What benefit would we get from script packages opposed to removal?

Dummy script packages are there for advertising system package information.

[mkoeppe]

comment:15

Replying to @jhpalmieri:

If someone uses a system Python without .supp files, can they use Sage-distributed .supp files instead? For what it's worth, homebrew doesn't seem to provide these

Yes, the idea of the sage-valgrind script is that it provides --suppressions options to valgrind.

I like the idea of this script, but the details need updating. I needed valgrind only once in the last 5 years and noticed that it was outdated but didn't have the energy to make the proper update. For such rare uses, an updated script (and a vendored copy of the Python suppressions -- note that they are NOT frequently updated upstream) would be of great value.

[mkoeppe]

comment:16

Replying to @jhpalmieri:

I was asking if there should be a new package that supplies the scripts, valgrind-sage-support or whatever. The point is to remove those rarely scripts from src/bin unless the user specifically requests them.

That would of course be possible; but I am not sure if it would be an improvement.

[orlitzky]

comment:17

Replying to @mkoeppe:

Replying to @orlitzky:

What benefit would we get from script packages opposed to removal?

Dummy script packages are there for advertising system package information.

Yeah, I know, but... do we really need to suggest installing gdb and valgrind to people? Installing them doesn't improve the normal sage experience. And anyone who's actually going to use them is aware of their existence.

[mkoeppe]

Replying to @jhpalmieri:

If someone uses a system Python without .supp files, can they use Sage-distributed .supp files instead? For what it's worth, homebrew doesn't seem to provide these

Yes, the idea of the sage-valgrind script is that it provides --suppressions options to valgrind.

I like the idea of this script, but the details need updating. I needed valgrind only once in the last 5 years and noticed that it was outdated but didn't have the energy to make the proper update. For such rare uses, an updated script (and a vendored copy of the Python suppressions -- note that they are NOT frequently updated upstream) would be of great value.

The scripts are updated in:

• Repair sage -t --valgrind #37569

The packages are reduced to dummy in:

• Reduce outdated gdb and valgrind packages to dummy packages #38306