bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

[pelzflorian (Florian Pelz)]

Hello all.

Ludovic Courtès <ludo@gnu.org> writes:
>>> I wonder if we should revert 482fda2729c3e76999892cb8f9a0391a7bd37119.
>>> It’s often not very helpful anyway (we often find ourselves downloading
>>> unnecessary package outputs because of grafting).
>>
>> Hmm.  Perhaps.  But it'd also suck to have to download 1 GiB of unneeded
>> debugging symbols to just apply a graft to Qt, for example.
>
> Yeah.  That’s already the case in some cases though, that’s what I
> meant.

I believe I got bitten by this 482fda2729c3e76999892cb8f9a0391a7bd37119
too, not only for debug symbols, which annoys me, and not like the Go
users, but for me the issue surfaced when trying to use guile-g-golf,
whose hello-world.scm errors out with “cannot register existing type
'GdkPixbuf'” and GDB debugging shows (I think) it is because a variant
of gdk-pixbuf without a debug output is used by Gtk while guile-g-golf
loads gdk-pixbuf with debug output before.  `guix shell --no-grafts` is
a workaround.

Perhaps guile-gi have the same issue.  Quoting
<https://github.com/spk121/guile-gi/issues/96>:
> It is pretty clear to me, that the main culprit here is a different
> version of GLib being linked to Guile-GI than the one that should be
> loaded through Guile-GI.

In essence it seems to me 482fda2729c3e76999892cb8f9a0391a7bd37119 is
implemented at the wrong level.  It changed the grafting derivation and
thus the hash, when it could probably be done in guix-daemon directly.

Is it better to wait with fixing this until the guix-daemon is rewritten
in Guile?  And use `--no-grafts' in the meantime?

Regards,
Florian