guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#65853] [PATCH] gnu: scilab: Fix and hardcode script inputs.


From: Nicolas Graves
Subject: [bug#65853] [PATCH] gnu: scilab: Fix and hardcode script inputs.
Date: Thu, 28 Sep 2023 20:30:58 +0200

On 2023-09-28 19:36, Efraim Flashner wrote:

> A couple of things I noticed:
>
> On Sun, Sep 10, 2023 at 06:18:42PM +0200, Nicolas Graves wrote:
>> +                  coreutils
>
> This can be coreutils-minimal
>

Will change it.
>> +                  (("grep")
>> +                   #$(file-append (this-package-input "grep") "/bin/grep"))
>
> These can be (search-input-file #$inputs "/bin/grep") to make it easier
> to swap out the packages for something else if people want.
>

Fine for me.

>> +                  (("sed")
>
> I checked the script, it should be ((" sed ") since there are a couple
> of instances of 'sed' in the script which aren't invocations of sed.

Yes I indeed noticed it too, probably forgot to resubmit a patch but my
local version works well.
>
>> +                   #$(file-append (this-package-input "sed") "/bin/sed"))
>> +                  (("uname")
>> +                   #$(file-append (this-package-input "coreutils")
>> +                                  "/bin/uname"))
>> +                  (("dirname")
>> +                   #$(file-append (this-package-input "coreutils")
>> +                                  "/bin/dirname"))
>> +                  (("basename")
>> +                   #$(file-append (this-package-input "coreutils")
>> +                                  "/bin/basename"))))))))
>
> Are there more binaries which should be substituted? I saw glxgears,
> chcon, a couple instances of java, pwd, valgrind, docbook paths. And
> then there's a couple of other scripts and binaries in the bin/ folder.
> I think it'd be better to use wrap-script or wrap-program and then use
> substitute* to strip the leading /usr/bin/ from the different calls to
> the different binaries.

I don't use more than that for a CLI usage. The thing is that we already
build without the GUI (so without java). Maybe valgrind could be useful
for debugging, docbook for documentation...

I'll take a look in the coming weeks, but I can guarantee it works for
me, so I propose we should process with this one, and add other patches
on top when someone needs them. But we should be mindful that all
possible paths / binaries are not reachable when the script is run
(IIRC, they also depend on the OS and options).

-- 
Best regards,
Nicolas Graves





reply via email to

[Prev in Thread] Current Thread [Next in Thread]