By doing this the up coming budgie-extras v1.0.2. doesn't need to be patched for binaries.
The result if we add --bindir=/usr/bin will be:
/usr/bin/free /usr/bin/pgrep /usr/bin/pidof /usr/bin/pkill /usr/bin/pmap /usr/bin/ps /usr/bin/pwdx /usr/bin/slabtop /usr/bin/tload /usr/bin/top /usr/bin/uptime /usr/bin/vmstat /usr/bin/w /usr/bin/watch
Also I should mention that procps-ng source has been moved from sourceforge to gitlab and updated to 3.3.16.
| R2481 procps-ng | |||
| R2481:2a56284b2655 Rebuild against tooling for path changes | |||
I need to see kernel testing that proves this doesn't break our initrd. Relevant entries from lsinitrd on the -current kernel:
-rwxr-xr-x 1 root root 18536 May 14 16:54 bin/free -rwxr-xr-x 1 root root 100688 May 14 16:54 bin/ps
Hi @DataDrake, I have installed this on my system with --bindir=/usr/bin and the system is launched. Not sure what I need to do to give more info.
Or maybe the Ubuntu Budgie folks could provide a meson option instead of having us change a significant package? Seems more reasonable.
Just finished building linux-current.
@JoshStrobl UB guys did something in this PR, but I think this doesn't help Solus if some of our executables are in /usr/bin and some other are in /bin.
@algent then I misunderstood the premise of this request and am hereby rescinding my approval to make this change. There is absolutely no reason why they should be using full paths for those executables. The function they are using to run commands is already equipped for searching PATH for anything it needs: https://valadoc.org/glib-2.0/GLib.Process.spawn_command_line_sync.html
I'll leave this open while you sort this out with upstream, but Solus isn't going to force a UsrMerge just because budgie-extras is overly picky.