https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain
== Summary == Remove Guile support from GDB and GNU Make packages.
== Owner == * Name: [[User:keiths| Keith Seitz]] * Email: keiths@redhat.com
== Detailed Description == GDB and Make packages currently contain Guile scripting support which allows users to implement (possibly new) functionality in these tools. This change request proposes to remove that support from the these tools, since both provide alternatives without the burden of additional dependencies.
== Benefit to Fedora ==
While GDB supplies a "minimal" package which disables all non-essential features for use in the buildroot, Make has no equivalent, and is always compiled with Guile support. This requires that the buildroot contains Guile. This proposal will help shrink the buildroot.
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.
== Scope == * Proposal owners: Update gdb/make spec files. * Other developers: Update Make/GDB scripting files if using Guile. No such users expected. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == Users with GDB and/or Make Guile scripts will need to update and/or rewrite their scripts.
== How To Test == GDB: There is nothing to test. If you are using Guile scripts, you should rewrite with Python.
Make: Rebuild packages if it is unknown whether they contain Guile scripts; otherwise, there is nothing to test.
== User Experience == Guile scripts that extend the functionality of GDB or Make will stop working when users upgrade these packages. GDB users are encouraged to use GDB's Python interface instead. Users of Guile in Makefiles should either use shell scripting or GNU Make's built-in language or migrate to another build tool with different scripting capabilities (such as CMake or Meson).
== Dependencies == N/A (not a System Wide Change)
== Contingency Plan == * Contingency mechanism: Revert changes and restore GDB/Make support for Guile. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change
== Documentation == N/A (not a System Wide Change)
== Release Notes == Release notes should mention the removal of Guile support in GDB/Make and suggest alternatives.
On Tue, Jan 12, 2021 at 3:57 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain
== Summary == Remove Guile support from GDB and GNU Make packages.
== Owner ==
- Name: [[User:keiths| Keith Seitz]]
- Email: keiths@redhat.com
== Detailed Description == GDB and Make packages currently contain Guile scripting support which allows users to implement (possibly new) functionality in these tools. This change request proposes to remove that support from the these tools, since both provide alternatives without the burden of additional dependencies.
== Benefit to Fedora ==
While GDB supplies a "minimal" package which disables all non-essential features for use in the buildroot, Make has no equivalent, and is always compiled with Guile support. This requires that the buildroot contains Guile. This proposal will help shrink the buildroot.
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.
== Scope ==
- Proposal owners: Update gdb/make spec files.
- Other developers: Update Make/GDB scripting files if using Guile. No
such users expected.
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == Users with GDB and/or Make Guile scripts will need to update and/or rewrite their scripts.
== How To Test == GDB: There is nothing to test. If you are using Guile scripts, you should rewrite with Python.
Make: Rebuild packages if it is unknown whether they contain Guile scripts; otherwise, there is nothing to test.
== User Experience == Guile scripts that extend the functionality of GDB or Make will stop working when users upgrade these packages. GDB users are encouraged to use GDB's Python interface instead. Users of Guile in Makefiles should either use shell scripting or GNU Make's built-in language or migrate to another build tool with different scripting capabilities (such as CMake or Meson).
== Dependencies == N/A (not a System Wide Change)
== Contingency Plan ==
- Contingency mechanism: Revert changes and restore GDB/Make support for Guile.
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change
== Documentation == N/A (not a System Wide Change)
== Release Notes == Release notes should mention the removal of Guile support in GDB/Make and suggest alternatives.
This is probably a bad idea, since that deliberately breaks things for things that expect it to be there. If we *really* want to get rid of this (and I'm not entirely convinced we should), why not just make an alternative build subpackage and make the two conflict? One with Guile support and one without? Then if something needs Guile integration for Make, for example, they can install "make-guile" instead of "make".
Also "shrink the buildroot" for Make isn't a good enough reason to do this, since we don't even include Make in the buildroot by default anymore[1].
[1]: https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
-- 真実はいつも一つ!/ Always, there's only one truth!
Neal Gompa wrote:
Also "shrink the buildroot" for Make isn't a good enough reason to do this, since we don't even include Make in the buildroot by default anymore[1].
But a lot of packages BuildRequire make, and the fact that it is not in the default BuildRoot actually makes this problem worse for users doing local builds, because this means that make and its dependencies are no longer included in the buildroot cache.
Kevin Kofler
On Tue, Jan 12, 2021 at 05:10:08PM -0500, Neal Gompa wrote:
On Tue, Jan 12, 2021 at 3:57 PM Ben Cotton bcotton@redhat.com wrote:
== Release Notes == Release notes should mention the removal of Guile support in GDB/Make and suggest alternatives.
This is probably a bad idea, since that deliberately breaks things for things that expect it to be there.
Note the "No such users expected." part above... Is anyone using the guile interface? I have heard it mentioned a few times in the context of the dependencies that this pulls in, but never about actual use.
Zbyszek
* Neal Gompa:
This is probably a bad idea, since that deliberately breaks things for things that expect it to be there. If we *really* want to get rid of this (and I'm not entirely convinced we should), why not just make an alternative build subpackage and make the two conflict? One with Guile support and one without? Then if something needs Guile integration for Make, for example, they can install "make-guile" instead of "make".
With those explicit dependencies on “make”, installing “make-guile” wouldn't allow you to build much else anymore. “make-guile” could perhaps provide “make”, but I'm a bit wary of such ambiguous dependencies among core packages.
In my opinion, the presence of Guile support in make is a disservice to our users because other distributions (including downstreams) do not have it, so it creates non-portable programs if it is ever used.
Also "shrink the buildroot" for Make isn't a good enough reason to do this, since we don't even include Make in the buildroot by default anymore[1].
It still has to be downloaded and installed for most C/C++ builds.
Thanks, Florian
On Tue, Jan 12, 2021 at 05:10:08PM -0500, Neal Gompa wrote:
This is probably a bad idea, since that deliberately breaks things for things that expect it to be there. If we *really* want to get rid of this (and I'm not entirely convinced we should), why not just make an alternative build subpackage and make the two conflict? One with Guile support and one without? Then if something needs Guile integration for Make, for example, they can install "make-guile" instead of "make".
A better way to do that is I think what GCC does e.g. with isl, patch the source so that for the very rarely if ever used feature it doesn't link against the corresponding library, but instead dlopens it and calls it through dlsym pointers. That way, make would not have the guile dependency, and if somebody ever tries to use the guile stuff, it would dlopen the library, if it isn't there, it would print some sensible diagnostics like that dnf install guilewhatever is needed to make it work and fail.
Jakub
* Jakub Jelinek:
A better way to do that is I think what GCC does e.g. with isl, patch the source so that for the very rarely if ever used feature it doesn't link against the corresponding library, but instead dlopens it and calls it through dlsym pointers. That way, make would not have the guile dependency, and if somebody ever tries to use the guile stuff, it would dlopen the library, if it isn't there, it would print some sensible diagnostics like that dnf install guilewhatever is needed to make it work and fail.
The functionality is sufficiently isolated for this to be possible, but given that there are no users of gmk-expand and gmk-eval, I really do not see the point.
Thanks, Florian