I'm managing/installing ROS packages on computers that runs inside my company. Because of our activities I need to very frequently update/change the packages on these machines. I make heavy use of desktop application install files (see https://gitlab.com/InstitutMaupertuis/ros_desktop_launcher_test) because my users are non programmers.
Currently my work-flow is the following one:
- One user per ROS machine
- SSH on the machine to pull the code and compile when needed
- Compile and install locally in a sub-home directory
I now want/need individual user accounts rather than one user per machine. What is the easiest way to install the ROS packages system wide on the machine?
My thoughts are:
- As many accounts as necessary per ROS machine (including 1 account for me)
- SSH on my account on the machine to pull the code and compile when needed
- Install with a
CMAKE_INSTALL_PREFIXlike/opt/ros/InstitutMaupertuis/ - Modify my ros_desktop_launcher_test examples so that desktop application files are installed in
/usr/local/share/applicationswhen theCMAKE_INSTALL_PREFIXdoes not start with/home/.
Is there a simpler way?
If not, how do I run catkin_make install with high privileges so that I can install my files anywhere in the system?
Originally posted by VictorLamoine on ROS Answers with karma: 1505 on 2018-06-27
Post score: 0
Original comments
Comment by gvdhoorn on 2018-06-27:
In our lab we either temporarily give a user write access to /opt, then chown root:root -R /opt or run sudo -E catkin_make install (or the equivalent for catkin_tools). Then use the install space in /opt as an underlay.
Comment by Simon Schmeisser on 2018-06-27:
why do you want to compile from code? We build a deb package (should be several ...), put it to a local repository and run apt upgrade. I can copy-paste some samples as an answer tomorrow
Comment by VictorLamoine on 2018-06-28:
Because I use different versions on different machines, and I need to keep track of them easily. Differencing version A of the package from version B is not easy when installed as a deb.
Comment by gvdhoorn on 2018-06-28:
Not pushing you to go for .debs, but I'm not sure I follow why determining the version of the installed packages would be difficult with them? dpkg -l | $pkgname shows me the version. Isn't that one of the advantages of using a pkg manager?
Comment by VictorLamoine on 2018-06-28:
Then I need to tweak the version number for each branch I create for a new functionality, which is tidy work. Debugging gets much harder with debs unless I compile / package on each target machine, but then it adds a lot of work and reduces the interest of having debs at all.
Comment by VictorLamoine on 2018-06-28:
I think debs are well suited for releasing, but in my case I am changing / testing a lot on each machine so I don't think it suits my needs.
Comment by gvdhoorn on 2018-06-28:
Fair enough.
I think debs are well suited for releasing
True. That is their main purpose. Running a buildfarm / buildbot would make this perhaps more managable, but might also be overkill in this situation.
Installing into /opt will also not make things easier though. That ..
Comment by gvdhoorn on 2018-06-28:
.. is a non world-writable location, so regular users would need to jump through some hoops to edit things there.
Or would you be debugging on your own system, then push updated stuff to the other machines?
Comment by VictorLamoine on 2018-06-28:
If the source code is on the machine where the problem happens then I just compile in debug mode and roslaunch manually to find out the problems (eg: with gdb). I could store the code on my user account and debug in that environment, then install in /opt so that all users of this machine get the fix
Comment by Simon Schmeisser on 2018-06-28:
you could still have a deb that installs to /opt and another linked ws for the single package that is to be debugged in /home/victor/
My colleagues prefer your approach, but I try to push them towards using debs more as that is the only way plausible off-site (@ a customer)
Comment by Simon Schmeisser on 2018-06-28:
note that you can have a debug package that you install whenever necessary
Comment by VictorLamoine on 2018-06-28:
Simon Schmeisser write your solution as an answer, I'll give it a try :)