Link /usr/bin/code-oss to wrapper rather than binary.
Details
Details
Diff Detail
Diff Detail
- Repository
- R3148 vscode
- Branch
- master
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
No. There is no reason for it to link to the wrapper. All the wrapper is doing is getting the VSCODE path, when it already defaults to the correct path already, and providing a rather unnecessary prompt regarding root.
Comment Actions
@j-c-m That's what child process detaching and using &! is for, but I guess if you feel this is the better way of going about it rather than basically the universal way of detaching from a process (or them implementing child process detaching upstream instead via child_process), then you'll need to:
- Increment the relnum
- Also include the pspec
- Include a test plan.
- Update this diff (it'll unmark as abandoned)
Additionally, the bash script should be cleaned up, none of the unnecessary checks for VSCODE_PATH, just set it to /usr/share/vscode
Comment Actions
@JoshStrobl On the child process detachment, I am indifferent, this is just how they implemented it upstream and generally what the package does on other distributions. I did note that aur patches out the VSCODE_PATH stuff, I'll give it a go to update this.
Comment Actions
Yea, I patch out some similar path checking for appdata (alongside performing a symlink to fix some extensions) in 0001-Attempt-to-symlink-.config-Code-to-.config-Code-OSS-.patch. Likely doesn't provide any sort of substantial change in startup performance but if any checks can be avoided (since we're able to make the assumption that we're on Linux and we already know the pathing), we may as well do it.
I'd recommend copy / pasting the wrapper into the files folder in the repo and editing it there. Then during the install phase you'd remove $installdir/$vsdir/bin/code-oss and install (likely need to do it with file permissions that permit execution) $pkgfiles/code-oss to $installdir/$vsdir/bin/code-oss, ideally prior to doing the symlink.