[bug#43249]

[Ricardo Wurmus]

Brendan Tildesley <mail@brendan.scot> writes:

> On 11/9/20 6:38 pm, Ricardo Wurmus wrote:
>> Brendan Tildesley <mail@brendan.scot> writes:
>>
>>> On 10/9/20 11:22 pm, Ricardo Wurmus wrote:
>>>> Brendan Tildesley <mail@brendan.scot> writes:
>>>>
>>>>> I guess then we should patch wrap-program to add
>>>>>
>>>>> (when (wrapper? prog)
>>>>>       (error (string-append prog " is a wrapper. Refusing to wrap.")))
>>>> Should it really refuse to wrap or *add* its variables to the existing
>>>> wrapper?
>>>>
>>> If there is a /bin/foo and /bin/.foo-real created by wrap-program, and
>>> we are to run another wrap-program phase, under what circumstances
>>> would it /not/ be a mistake to call (wrap-program "/bin/.foo-real")
>>> instead of (wrap-program "/bin/foo")? And if the first one was called,
>>> probably it was because find-files was used and the packager didn't
>>> realise it was happening, and therefore it will be double-wrapped,
>>> like gedit is.
>> Oh, yes, that would be a mistake.
>>
> While we're at it, what do you think about changing the moved file
> from /bin/.foo-real into /bin/.real/foo, or maybe it would have to go
> up a directory and go into /.bin-real/foo. That would mean all these
> dot files wouldn't pollute PATH and appear in things like bemenu, or
> in window titles. Also pkill should be able to kill correctly based on
> the name. Would it break more things somehow?

I’d rather not move these things to other directories because some
applications are very sensitive to relative location.

I think we should be using “wrap-script” where possible (because many
wrapped applications really are scripts) and think of another in-place
wrapping mechanism for binaries.

-- 
Ricardo