[bug#53020] [PATCH] gnu: racket: Backport fix for .desktop files.

[Philip McGrath]

Hi,

On 1/5/22 03:59, zimoun wrote:
> So my naive question is: is it worth to include now and not just wait
> for the next Racket 8.4 release? (One or two months if Racket keep the 4
> releases per year schedule)
>
> Other said, for testing new Racket features in the Guix ecosystem, it
> appears to me easier to use transformation:
>
>      guix build racket-minimal --with-commit=ece8b17
>
> (or something along this line :-))
>
> BTW, thanks for bridging the gap between Guix and Racket and it can be
> cool if Guix can help Racket. :-)

Certainly it is debatable, and it would be useful even just to have more 
Guix people try out this patch, but, in my opinion, it is worth it to 
include this in Guix now and not just wait for the Racket 8.4 release 
(in about a month, if all goes according to schedule). (But perhaps 
that's not so surprising that I think so, since I sent this patch.)

I see basically two considerations that distinguish this case from 
recruiting Guix for Racket's pre-release testing, which I generally 
wouldn't suggest.

First, this fixes a very annoying regression in Guix's Racket packaging 
introduced (by me) in Guix commit 
65bad4d03684a32598e0c6fb3449e481e37acfde (the switch to make 'racket' a 
config-tethered installation layer on top of 'racket-minimal'), in 
which, though I didn't notice it at the time, the 'racket' package 
stopped building/installing "share/applications/drracket.desktop". 
Symptoms include DrRacket not showing up in desktop application menus, 
disruption to the handling of ".rkt" files, and various other 
annoyances. (Time will tell, but I suspect it may have been the culprit 
behind some Wayland troubles that non-Guix users haven't been able to 
reproduce.)

Second, the Racket patches are changes to the low-level support for 
"layered" and "tethered" installations. Guix's 'racket' package is a 
major high-level use of that low-level support, e.g. Matthew Flatt 
filled in some missing parts of that low-level support to make the 
above-referenced Guix commit possible. So, while this isn't quite a 
Guix-specific fix, it's fairly close. I'm convinced that this it is an 
improvement, and it seems like a complete solution, but there's still 
time to make any adjustments that might turn out to be needed before the 
8.4 release, when Racket's strong compatibility commitments kick in. In 
the best case, which I think is most likely, Guix users get a fix for an 
annoying packaging bug early; in the worst case, we get a partial fix 
now and a chance to identify anything that still needs to be fixed.

I explained in my reply to Malte why the command-line package 
transformation doesn't quite work: that's not inherently part of these 
considerations, but perhaps it does further suggest that this fix is 
unusually closely connected to the way Guix packages Racket.

-Philip