-1

@keiths Can you respond to the questions that were raised on the mailing list? It looks like people (including me) would like to know a more detailed impact analysis (other than "your stuff will break if you used this"), for example, which packages are actually currently using this functionality (if any).

@ngompa do you know of actual use cases that will be impacted by this?

I don't know anybody who is using this, moreover other distros don't even enable this.

+1 from me

@keiths, @ngompa ping

I am attempting to ascertain whether any package actually uses guile/Make, but that will obvious take several days. [It doesn't help that I didn't actually see any feedback because my devel subscription was not delivering messages.]

I don't know anybody who is using this, moreover other distros don't even enable this.

This is not true. It is enabled in Debian/Ubuntu (with make-guile) and Arch (standard make).

(from https://qa.debian.org/popcon-graph.php?packages=make%2Cmake-guile&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1)

This suggests that dropping it will not have a big impact.

You need to look for the actual macros:

• https://codesearch.debian.net/search?q=gmk-eval&literal=1&perpkg=1
• https://codesearch.debian.net/search?q=gmk-expand&literal=1&perpkg=1
• https://codesearch.debian.net/search?q=gmk-var&literal=1&perpkg=1

The kbuild usage is not present in the kernel tree. A feature test by itself is not evidence of use, either.

If the Debian corpus doesn't show any uses, it's hard to believe that they exist.

There are two problems with this discussion:

• The catch-22 of "nobody will use it if it isn't available"
• We provide things in the distribution that third parties can use without telling us anything about it (e.g. extra Python interpreters, cpanm, etc)

I personally do not accept that it's okay to remove a feature that developers can use unless it's broken, deprecated, or has some fundamental problem upstream. None of these things are true in this scenario, so the burden of proof to actually remove Guile support from GDB and Make is extremely high in my book.

Moreover, neither GDB nor Make are even part of the base buildroot anymore. And buildroot minimization to the extreme makes life pretty miserable for all of us. When the Minimization Objective was being discussed, I asked if we were going to pursue minimization at all costs, and the answer was "no, we're going to be sensible about this and not reduce functionality in the process".

Also, there's a weird statement in the change document:

Furthermore, GDB already supports a much more widely tested and feature-rich Python interface, and maintainers would like to remove the maintenance burden imposed by supporting multiple scripting interfaces.

This is malarkey. Everyone involved in the GNU Toolchain in Fedora are upstream developers. You have to maintain this no matter what anyway. Unless upstream is removing Guile support for these two projects, we shouldn't do it either.

After a week, I count the vote as (+1,0,-1). Tagging for meeting.

I have no objection to this change. Given that Python is available for gdb extension, that feels sufficient and even more maintainable.

+1

This was discussed in today's FESCo meeting:
REJECTED (+4, 2, -2).