[bug#43249]

[Brendan Tildesley <mail@brendan.scot>]

On 9/9/20 5:57 am, Ricardo Wurmus wrote:
> Prafulla Giri <pratheblackdiamond@gmail.com> writes:
>
>> I wonder.... perhaps it'd be better altogether if the (wrap-program)
>> procedure could be re-written to not make ..*.real.real programs...? That
>> would save us a lot of code-duplication...
> Looking at the definition of wrap-program in (guix build utils) there is
> code that checks if the wrapper already exists; if it does it should
> append the new environment variable definitions to the existing
> wrapper.  It looks like this doesn’t work reliably.
>
> If someone could figure out why that is we could fix this in the next
> core-updates cycle.
>
When given "foo", wrap-program checks if ".foo-real" exists and thus 
concludes that "foo" is a wrapper and appends, however, despite the fact 
that the wrapper? procedure exists, it is not actually used at any time 
to check if ".foo-real" its self was passed to wrap-program. Therefore 
it happily wraps wrappers if it is given one. For example 
glib-or-gtk-build-system uses (find-files bindir ".*") to find files to 
pass to wrap-program. This ".*" regular expression matches hidden 
dotfiles. I copy-pasted everything to make a new build system and added 
an error for (wrapper? prog) and it exposed this. changingI guess then 
we should patch wrap-program to add

(when (wrapper? prog)
     (error (string-append prog " is a wrapper. Refusing to wrap.")))

at the start.

Then fix all uses of wrap-program so that they dont recieve -real files.

In glib-or-gtk-build-system.scm, chanding bin-list to:

(bin-list     (filter (lambda (file) (not (wrapper? file)))
                                      (append (find-files bindir ".*")
                                              (find-files libexecdir 
".*"))))

seems to fix it, at least in the case of gedit, a program that currently 
produces a nested wrapper. Ill play with it more tomorrow.