ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

How do I install compiled packages system wide?

asked 2018-06-27 09:25:42 -0500

VictorLamoine gravatar image

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 ) 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_PREFIX like /opt/ros/InstitutMaupertuis/
  • Modify my ros_desktop_launcher_test examples so that desktop application files are installed in /usr/local/share/applications when the CMAKE_INSTALL_PREFIX does 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?

edit retag flag offensive close merge delete



In our lab we either temporarily give a user write access to /opt, then chown root:root -R /optor run sudo -E catkin_make install (or the equivalent for catkin_tools). Then use the install space in /opt as an underlay.

gvdhoorn gravatar image gvdhoorn  ( 2018-06-27 10:48:37 -0500 )edit

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

Simon Schmeisser gravatar image Simon Schmeisser  ( 2018-06-27 14:18:27 -0500 )edit

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.

VictorLamoine gravatar image VictorLamoine  ( 2018-06-28 02:00:02 -0500 )edit

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?

gvdhoorn gravatar image gvdhoorn  ( 2018-06-28 02:30:25 -0500 )edit

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.

VictorLamoine gravatar image VictorLamoine  ( 2018-06-28 02:40:20 -0500 )edit

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.

VictorLamoine gravatar image VictorLamoine  ( 2018-06-28 02:41:37 -0500 )edit

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 ..

gvdhoorn gravatar image gvdhoorn  ( 2018-06-28 02:46:33 -0500 )edit

.. 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?

gvdhoorn gravatar image gvdhoorn  ( 2018-06-28 02:47:20 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-01-28 16:52:21 -0500

VictorLamoine gravatar image

The easiest solution is to create debian packages through bloom locally; I have created some scripts that helps with this task:

An example usage can be found here:

With these scripts you will be able to release your packages without disclosing the source code to anyone, and it handles dependencies between projects nicely.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2018-06-27 09:25:42 -0500

Seen: 573 times

Last updated: Jan 28 '19