ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Can you clone rospkg somewhere, and add the output of python /path/to/rospkg/src/rospkg/os_detect.py to your question? That should tell us whether CentOS is correctly detected or not. Could be that something's changed from v5 and 6.

Can you clone rospkg somewhere, and add the output of python /path/to/rospkg/src/rospkg/os_detect.py to your question? That should tell us whether CentOS is correctly detected or not. Could be that something's changed from v5 and 6.

If the output is ok, it's probably rosdep that can't find any mappings for centos for the pkgs that need to be installed (your console copy/paste suggests that).

You could try and see whether overriding the detected OS by setting ROS_OS_OVERRIDE=fedora:21 (or some other value for the version) in the shell before running rosdep install .. (for rosdep specially, you'll probably want to add --os=fedora:21 to the arguments. It used to be the case that rosdep did not always work correctly with ROS_OS_OVERRIDE alone).

Fedora is not CentOS, but could be close enough for it to work (rosdep installs system dependencies, not actual compiled ROS binaries).

I'd recommend to leave off the -y at the end of the rosdep command line, so it needs confirmation before each command. That should give you the opportunity to make sure it doesn't try to do something strange / unwanted.

Can you clone rospkg somewhere, somewhere (if you don't already have it), and add the output of python /path/to/rospkg/src/rospkg/os_detect.py to your question? That should tell us whether CentOS is correctly detected or not. Could be that something's changed from v5 and 6.

If the output is ok, it's probably rosdep that can't find any mappings for centos for the pkgs that need to be installed (your console copy/paste suggests that).

You could try and see whether overriding the detected OS by setting ROS_OS_OVERRIDE=fedora:21 (or some other value for the version) in the shell before running rosdep install .. (for rosdep specially, you'll probably want to add --os=fedora:21 to the arguments. It used to be the case that rosdep did not always work correctly with ROS_OS_OVERRIDE alone).

Fedora is not CentOS, but could be close enough for it to work (rosdep installs system dependencies, not actual compiled ROS binaries).

I'd recommend to leave off the -y at the end of the rosdep command line, so it needs confirmation before each command. That should give you the opportunity to make sure it doesn't try to do something strange / unwanted.

Can you clone rospkg somewhere (if you don't already have it), and add the output of python /path/to/rospkg/src/rospkg/os_detect.py to your question? That should tell us whether CentOS is correctly detected or not. Could be that something's changed from v5 and 6.

If the output is ok, it's probably rosdep that can't find any mappings for centos for the pkgs that need to be installed (your console copy/paste suggests that).

You could try and see whether overriding the detected OS by setting ROS_OS_OVERRIDE=fedora:21 (or some other value for the version) in the shell before running rosdep install .. (for rosdep specially, you'll probably want to add --os=fedora:21 to the arguments. It used to be the case that rosdep did not always work correctly with ROS_OS_OVERRIDE alone).alone). See wiki/ROS/EnvironmentVariables - ROS_OS_OVERRIDE for some comments on that environment variable.

Fedora is not CentOS, but could be close enough for it to work (rosdep installs system dependencies, not actual compiled ROS binaries).

I'd recommend to leave off the -y at the end of the rosdep command line, so it needs confirmation before each command. That should give you the opportunity to make sure it doesn't try to do something strange / unwanted.

Can you clone rospkg somewhere (if you don't already have it), and add the output of python /path/to/rospkg/src/rospkg/os_detect.py to your question? That should tell us whether CentOS is correctly detected or not. Could be that something's changed from v5 and 6.

If the output is ok, it's probably rosdep that can't find any mappings for centos for the pkgs that need to be installed (your console copy/paste suggests that).

You could try and see whether overriding the detected OS by setting ROS_OS_OVERRIDE=fedora:21 (or some other value for the version) in the shell before running rosdep install .. (for rosdep specially, you'll probably want to add --os=fedora:21 to the arguments. It used to be the case that rosdep did not always work correctly with ROS_OS_OVERRIDE alone). See wiki/ROS/EnvironmentVariables - ROS_OS_OVERRIDE for some comments on that environment variable.

Fedora is not CentOS, but could be close enough for it to work (rosdep installs system dependencies, not actual compiled ROS binaries).

I'd recommend to leave off the -y at the end of the rosdep command line, so it needs confirmation before each command. That should give you the opportunity to make sure it doesn't try to do something strange / unwanted.


Edit:

output of os_detect.py

OS Name:     centos
OS Version:  7.1.1503
OS Codename: core

That looks ok.

output of

rosdep install --from-paths src --ignore-src --rosdistro indigo --os=fedora:21
[..]
No package collada-dom-devel available.
[..]

So rosdep now uses the keys for Fedora to map to system dependencies. As I wrote earlier before, that could have worked, but apparently some packages do not exist on CentOS 7 (or perhaps have a different name).

Looking at pkgs.org for collada-dom-devel fi shows only pkgs for CentOS 6 and some Fedora versions. The same is true for the other pkgs that yum couldn't find.

Some options I can come up with:

  1. install the dependencies that yum can't find by hand (either from source, or from some CentOS 7 compatible RPM you find somewhere), and get rosdep to skip the keys for those pkgs if it can't detect that they have been installed (mostly the case when you install things from source. See the rosdep command line docs, --skip-keys)
  2. if the packages do exist on CentOS 7, but under a different name, contribute some new rules for rosdep so that it can resolve them on the centos OS key it detected (see rosdep - Contributing rosdep rules). That would probably also remove the need to override the detected OS (if there are sufficient rules for CentOS)
  3. completely avoid installing on CentOS itself altogether, by using the recently introduced docker support. See wiki/docker for tutorials
  4. install the missing dependencies using the Fedora RPMs. This is really not recommended, as there are probably ABI incompatibilities between CentOS and Fedora
  5. limit your ROS install to a subset of packages that do not depend on dependencies that are not supported on CentOS 7. This will be hard though, as collada-dom is a dependency of a rather 'core' ROS sub-system (and so is pydot and some others). That would limit the usefulness of your install considerably.

There are probably others, perhaps other users can suggest some other alternatives.

Can you clone rospkg somewhere (if you don't already have it), and add the output of python /path/to/rospkg/src/rospkg/os_detect.py to your question? That should tell us whether CentOS is correctly detected or not. Could be that something's changed from v5 and 6.

If the output is ok, it's probably rosdep that can't find any mappings for centos for the pkgs that need to be installed (your console copy/paste suggests that).

You could try and see whether overriding the detected OS by setting ROS_OS_OVERRIDE=fedora:21 (or some other value for the version) in the shell before running rosdep install .. (for rosdep specially, you'll probably want to add --os=fedora:21 to the arguments. It used to be the case that rosdep did not always work correctly with ROS_OS_OVERRIDE alone). See wiki/ROS/EnvironmentVariables - ROS_OS_OVERRIDE for some comments on that environment variable.

Fedora is not CentOS, but could be close enough for it to work (rosdep installs system dependencies, not actual compiled ROS binaries).

I'd recommend to leave off the -y at the end of the rosdep command line, so it needs confirmation before each command. That should give you the opportunity to make sure it doesn't try to do something strange / unwanted.


Edit:

output of os_detect.py

OS Name:     centos
OS Version:  7.1.1503
OS Codename: core

That looks ok.

output of

rosdep install --from-paths src --ignore-src --rosdistro indigo --os=fedora:21
[..]
No package collada-dom-devel available.
[..]

So rosdep now uses the keys for Fedora to map to system dependencies. As I wrote earlier before, that could have worked, but apparently some packages do not exist on CentOS 7 (or perhaps have a different name).

Looking at pkgs.org for collada-dom-devel fi shows only pkgs for CentOS 6 and some Fedora versions. The same is true for the other pkgs that yum couldn't find.

Some options I can come up with:

  1. install the dependencies that yum can't find by hand (either from source, or from some CentOS 7 compatible RPM you find somewhere), and get rosdep to skip the keys for those pkgs if it can't detect that they have been installed (mostly the case when you install things from source. See the rosdep - command line docsreference, --skip-keys)
  2. if the packages do exist on CentOS 7, but under a different name, contribute some new rules for rosdep so that it can resolve them on the centos OS key it detected (see rosdep - Contributing rosdep rules). That would probably also remove the need to override the detected OS (if there are sufficient rules for CentOS)
  3. completely avoid installing on CentOS itself altogether, by using the recently introduced docker support. See wiki/docker for tutorials
  4. install the missing dependencies using the Fedora RPMs. This is really not recommended, as there are probably ABI incompatibilities between CentOS and Fedora
  5. limit your ROS install to a subset of packages that do not depend on dependencies that are not supported on CentOS 7. This will be hard though, as collada-dom is a dependency of a rather 'core' ROS sub-system (and so is pydot and some others). That would limit the usefulness of your install considerably.

There are probably others, perhaps other users can suggest some other alternatives.