Fedora 34 Change: Remove Guile Support From Toolchain (Self-Contained Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain


== Summary ==
Remove Guile support from GDB and GNU Make packages.

== Owner ==
* Name: [[User:keiths| Keith Seitz]]
* Email: keiths(a)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.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Neal Gompa]

On Tue, Jan 12, 2021 at 3:57 PM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)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!

[Kevin Kofler]

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].
>  
>  [1]: https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot 
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

[Zbigniew Jędrzejewski-Szmek]

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(a)redhat.com&gt;
> 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

[Florian Weimer]

* 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].
>
>  [1]: https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot 
It still has to be downloaded and installed for most C/C++ builds.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

[Jakub Jelinek]

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

[Florian Weimer]

* 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
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill