How do I install compiled packages system wide?
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... ) 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?
In our lab we either temporarily give a user write access to
/opt, thenchown root:root -R /optor runsudo -E catkin_make install(or the equivalent forcatkin_tools). Then use the install space in/optas an underlay.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
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.
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 | $pkgnameshows me the version. Isn't that one of the advantages of using a pkg manager?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.
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.
Fair enough.
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
/optwill also not make things easier though. That .... 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?