Created attachment 928838 [details, diff] Patch to set permission during install After each update of clion, I need to manually set the execution flag of the /opt/clion/bin/clion binary. This is quite annoying. It would be nice if it is set directly when installing. ``` # ll /opt/clion/bin/clion -rw-r--r-- 1 root root 776528 May 14 09:53 /opt/clion/bin/clion ``` All that needs to be done is to add the clion executable to the fperm call during install.
Created attachment 928839 [details] emerge --info
Probably, `remote-dev-server` should be added as well ``` # file /opt/clion/bin/remote-dev-server /opt/clion/bin/remote-dev-server: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, stripped # ll /opt/clion/bin/remote-dev-server -rw-r--r-- 1 root root 776528 May 14 09:53 /opt/clion/bin/remote-dev-server ```
(In reply to Dustin Polke from comment #0) > Created attachment 928838 [details, diff] [details, diff] > Patch to set permission during install > > After each update of clion, I need to manually set the execution flag of the > /opt/clion/bin/clion binary. This is quite annoying. It would be nice if it > is set directly when installing. > > ``` > # ll /opt/clion/bin/clion > -rw-r--r-- 1 root root 776528 May 14 09:53 /opt/clion/bin/clion > ``` > > All that needs to be done is to add the clion executable to the fperm call > during install. I have not observed this due to the fact that clion is being launched via UI / desktop icon. Thank you for reporting. I understand you are using the executable via absolute path, and it should definitely be available as executable, I will push for a 2025.1-r2 today/tomorrow. But the /usr/bin/clion (which executes /opt/clion/bin/clion) is executable: localpc # ls -la /usr/bin/clion -rwxr-xr-x 1 root root 44 Apr 29 22:24 /usr/bin/clion Using it as simple user via /usr/bin/clion works on my side: local@localpc ~ $ /usr/bin/clion [0.002s][warning][cds] Archived non-system classes are disabled because the java.system.class.loader property is specified (value = "com.intellij.util.lang.PathClassLoader"). To use archived non-system classes, this property must not be set 2025-05-15 18:29:59,594 [ 160] WARN - sun.util.locale.provider.LocaleProviderAdapter - COMPAT locale provider will be removed in a future release Installation home directory: file:////opt/clion System directory: file:////home/local/.cache/JetBrains/CLion2025.1 Config directory: file:////home/local/.config/JetBrains/CLion2025.1 Log directory: file:////home/local/.cache/JetBrains/CLion2025.1/log Debug | ByteBufferAsyncProcessor | 44:DefaultDispatcher-worker-20 | PAUSE ('Socket not connected') :: {id = FrontendToBackend/Sender, state = 'Initialized'} Debug | Server | 74:FrontendToBackend | FrontendToBackend: listening /127.0.0.1:36835 (...) The installation of the /usr/bin/clion is being done by the ebuild. The (In reply to Dustin Polke from comment #2) > Probably, `remote-dev-server` should be added as well > > ``` > # file /opt/clion/bin/remote-dev-server > /opt/clion/bin/remote-dev-server: ELF 64-bit LSB pie executable, x86-64, > version 1 (SYSV), dynamically linked, interpreter > /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, stripped > > # ll /opt/clion/bin/remote-dev-server > -rw-r--r-- 1 root root 776528 May 14 09:53 /opt/clion/bin/remote-dev-server > ``` The remote-dev-server is being taken care of by the CLion itself, including the permissions.
/usr/bin/clion executes /opt/clion/bin/clion.sh, not /opt/clion/bin/clion I don't know why they both exist or what is the difference.
(In reply to Viorel Munteanu from comment #4) > /usr/bin/clion executes /opt/clion/bin/clion.sh, not /opt/clion/bin/clion > > I don't know why they both exist or what is the difference. Apologies, I meant /opt/clion/bin/clion.sh. Yes. Normally users can use /usr/bin/clion directly as executable either via desktop icon, or terminal via user, and they would pass through the clion.sh. The clion.sh starts java engine with transparent settings, and does not use the /opt/clion/bin/clion directly (from what I remember and from what I saw). This provides some visibility on how settings are done. But I would like to know why would we use the binary itself from /opt/clion/bin/clion, as well. Not that I would mind giving it executable permissions as well.
The reason why I switch from using /usr/bin/clion which calls then the /opt/clion/bin/clion.sh is that you get a pop-up in the IDE after starting this way saying: ``` The IDE seems to be launched with a script launcher ('bin/clion.sh'). Please consider switching to a native launcher ('bin/clion') for better experience. ``` It has a button that redirects to the following url explaining what is the benefit from using not the script: https://youtrack.jetbrains.com/articles/SUPPORT-A-56/How-to-handle-Switch-to-a-native-launcher-notification
