6.8 KiB
| title | date | draft |
|---|---|---|
| Contributing patches to source-based distributions, and the importance of doing so | 2021-09-01T21:58:17+02:00 | true |
Motivation
I've recently been trying to look into GDB's power-user features, in an weak attempt to stop spraying panicked logging all over my programs each time I run into a problem. As it turns out, GDB has plenty of hidden gems and tricks to the brave few who venture into its docs. For example, it includes a full Python interpreter that you can invoke from its CLI. It is often used to write custom pretty-printers, among other things.
Technically, Python is not a strict dependency of GDB, but rather an optional one if one chooses to run it with integrated Python support. But since Python is ubiquitous among the majority of GNU/Linux (or GNU+Linux, wink wink) distributions, there is no harm in including it by default. Debian, Arch, Gentoo, Void Linux, etc. all include it by default.
So far, so good. But I also found out that GDB has guile support, too. If you're not familiar with it, GNU Guile is GNU's implementation of Scheme, which they also have been steadily adding to many of their programs for things like scripting. I am quite fond of lisp languages, so I decided to try it myself. However, Guile does not enjoy Python's ubiquity: you will most likely encounter this error if you attempt executing guile code from GDB:
$ gdb -batch -n -ex "gu (+ 1 2)"
Guile scripting is not supported in this copy of GDB.
However, a typical installation will execute Python just fine:
$ gdb -batch -n -ex "py print(1 + 2)"
3
Void, Debian, Ubuntu, Gentoo, and I guess that almost all distros would fail here. The only one that includes it by default is Arch Linux. This means, however, that Arch has included guile-2.2 as a dependency of GDB for a quite obscure piece of functionality that most people won't care about. This is the tradeoff that distro mantainers make for us: Arch has opted for the bateries-included approach. Most of its packages pleasantly work for anything you'd need out of the box, at the cost of increased disk bloat and dependencies.
Reflecting on source distributions
If I was using a binary distribution, I'd be out of luck. However, I am a Gentoo citizen so, in exchange for my time, I get to make whichever tradeoffs I want myself. Gentoo packages usually have USE flags, an abstraction over whichever method the program is question uses to configure its compile-time parameters. But, if I check GDB's list of USE flags, I see no such flag:
$ equery -N u gdb | grep guile
$
...
I already know from peeking into GDB's source tree that its compile phase accepts the --with-guile=<yes/no/auto/version> argument, I only have to expose it past the .ebuild.
Looking into its commit history, I can see that guile support had been dropped circa 2015, which is a somewhat long time ago. I check guile's package status:
$ eix -l0 guile
[I] dev-scheme/guile
Available versions:
(12)
[M] 1.8.8-r3 (12/8)^t [debug debug-freelist debug-malloc +deprecated discouraged emacs networking nls readline +regex +threads] Matt Turner <mattst88@gentoo.org> (2019-09-01) TeXmacs is the only remaining package in tree that requires guile-1.8, which is unsupported upstream. A TeXmacs port to Guile-2 has been in progress for a few years. Bug #436400
2.0.14-r4 (12/22) [debug debug-malloc +deprecated +networking +nls +regex +threads] ["regex"]
2.2.6 (12/2.2-1)^s [debug debug-malloc +deprecated +networking +nls +regex +threads] ["regex"]
2.2.7-r1 (12/2.2-1)^s [debug debug-malloc +deprecated +networking +nls +regex +threads] ["regex"]
[M]~ 3.0.7 (12/3.0-1)^s [debug debug-malloc +deprecated +jit +networking +nls +regex +threads] ["regex"] Sam James <sam@gentoo.org> (2020-10-05) Masked for testing. New major versions of Guile often break reverse dependencies. Guile in Gentoo is not slotted, so let's be cautious. bug #705554, bug #689408.
Installed versions: 2.2.7-r1(12/2.2-1)^s(17:37:48 15/08/21)(deprecated networking nls regex threads -debug -debug-malloc)
Homepage: https://www.gnu.org/software/guile/
There are three non-masked versions, which in Gentoo parlance would mean something like "stable". Furthermore, GDB is compatible with versions 2.0, 2.2 and 3.0. It should then be perfectly OK to introduce the flag again.
Preparing the grounds
Creating a custom, local ebuild for GDB that lets me compile it differently from upstream Gentoo and never letting anyone know is perfectly acceptable and good. However, it's good practice to share such improvements with the community. The method for contributing package ebuilds to the project has changed over the years, moving from its bugzilla to GitHub's pull requests on the Gentoo mirror repository. They don't get merged using GH, but rather the devs manually apply accepted commit patches to the underlying Gentoo git, much like projects based around mail lists. Even if it is just a mirror of their own architecture, I can't say I feel too happy about this ad-hoc manouver. Oh well. Submitting git patches via bugzilla also seems like it's still an option.
For reasons of licensing, these commits need to be signed, both in the private-key and the real-name way. Gentoo makes it sound needlessly ominous, calling it GLEP 76's Certificate of Origin. In practical terms, it just means that commit messages we intent to merge into upstream should include this footer:
Signed-off-by: Full name <e-mail>
Where you are actually supposed to actually write the <> brackets. For working programmers that can't hand over the copyright of their code or folks that don't want to share their identitied, it would be better to simply poke other people into writing these patches themselves via mail list or irc.
I, however, am a magnanimous Godentoo user. If I am to submit a pull request, the first thing would be cloning Gentoo's github repository, containing the build instructions for all standard packages. Following "Repository Settings" section in this user guide you get a repo ready for experimentation.