Revision history [back]

but I don't know what value to put for the OS since Solus isn't built on any other distro.

OS detection is used for (mostly) two things in ROS:

1. determining the name of packages that provide system dependencies (ie: libraries and headers in the C++ case, modules and scripts for Python, etc)
2. figuring out which package manager to use to install those packages

To add support for a new OS, you'll have to figure out how that OS does its package management.

Ad 1: this comes down to providing mapping rules for rosdep keys to actual package names that Solus recognises. See #q215059 for some info on rosdep and why that is used in ROS, in addition to an example of such a mapping. You'll have to determine which packages map to which rosdep keys and add those to the database. After that, rosdep should know that boost maps to libboost-devel on Solus. It now needs to know how to install it, see below.

Ad 2: does Solus have a package manager? If so, how does it work? Does it use the pkg manager from another OS? If the answer is yes, ROS_OS_OVERRIDE could help. If not, you'll probably have to add a package manager 'plugin' to rosdep so it can communicate with whatever Solus uses.

Concluding: ROS_OS_OVERRIDE can be useful, but only if your target OS is (relatively) similar to an already supported OS (ie: Elementary OS may use the Ubuntu supported infrastructure, as it is a derivative).

If you can't do this for Solus, you'll have to add support, as described above.

but I don't know what value to put for the OS since Solus isn't built on any other distro.

OS detection is used for (mostly) two things in ROS:

1. determining the name of packages that provide system dependencies (ie: libraries and headers in the C++ case, modules and scripts for Python, etc)
2. figuring out which package manager to use to install those packages

To add support for a new OS, you'll have to figure out how that OS does its package management.management (or, in the absence of a package concept, installs new software in general).

Ad 1: this comes down to providing mapping rules for rosdep keys to actual package names that Solus recognises. See #q215059 for some info on rosdep and why that is used in ROS, in addition to an example of such a mapping. You'll have to determine which packages map to which rosdep keys and add those to the database. After that, rosdep should know that boost maps to libboost-devel on Solus. It now needs to know how to install it, see below.

Ad 2: does Solus have a package manager? If so, how does it work? Does it use the pkg manager from another OS? If the answer is yes, ROS_OS_OVERRIDE could help. If not, you'll probably have to add a package manager 'plugin' to rosdep so it can communicate with whatever Solus uses.

Concluding: ROS_OS_OVERRIDE can be useful, but only if your target OS is (relatively) similar to an already supported OS (ie: Elementary OS may use the Ubuntu supported infrastructure, as it is a derivative).

If you can't do this for Solus, you'll have to add support, as described above.

but I don't know what value to put for the OS since Solus isn't built on any other distro.

OS detection is used for (mostly) two things in ROS:

1. determining the name of packages that provide system dependencies (ie: libraries and headers in the C++ case, modules and scripts for Python, etc)
2. figuring out which package manager to use to install those packages

To add support for a new OS, you'll have to figure out how that OS does its package management (or, in the absence of a package concept, installs new software in general).

Ad 1: this comes down to providing mapping rules for rosdep keys to actual package names that Solus recognises. See #q215059 for some info on rosdep and why that is used in ROS, in addition to an example of such a mapping. You'll have to determine which packages map to which rosdep keys and add those to the database. After that, rosdep should know that boost maps to libboost-devel on Solus. It now needs to know how to install it, see below.

Ad 2: does Solus have a package manager? If so, how does it work? Does it use the pkg manager from another OS? If the answer is yes, ROS_OS_OVERRIDE could help. If not, you'll probably have to add a package manager 'plugin' to rosdep so it can communicate with whatever Solus uses.

Concluding: ROS_OS_OVERRIDE can be useful, but only if your target OS is (relatively) similar to an already supported OS (ie: Elementary OS may use the Ubuntu supported infrastructure, as it is a derivative).

If you can't do this for Solus, you'll have to add support, as described above.

$ docker run -it --rm ros:lunar-ros-core \
     rosdep install \
     --simulate \
     --reinstall \
     --ignore-src \
     --from-paths /opt/ros/lunar \
     --rosdistro=lunar

but I don't know what value to put for the OS since Solus isn't built on any other distro.

OS detection is used for (mostly) two things in ROS:

1. determining the name of packages that provide system dependencies (ie: libraries and headers in the C++ case, modules and scripts for Python, etc)
2. figuring out which package manager to use to install those packages

To add support for a new OS, you'll have to figure out how that OS does its package management (or, in the absence of a package concept, installs new software in general).

Ad 1: this comes down to providing mapping rules for rosdep keys to actual package names that Solus recognises. See #q215059 for some info on rosdep and why that is used in ROS, in addition to an example of such a mapping. You'll have to determine which packages map to which rosdep keys and add those to the database. After that, rosdep should know that boost maps to libboost-devel on Solus. It now needs to know how to install it, see below.

Ad 2: does Solus have a package manager? If so, how does it work? Does it use the pkg manager from another OS? If the answer is yes, ROS_OS_OVERRIDE could help. If not, you'll probably have to add a package manager 'plugin' to rosdep so it can communicate with whatever Solus uses.

Concluding: ROS_OS_OVERRIDE can be useful, but only if your target OS is (relatively) similar to an already supported OS (ie: Elementary OS may use the Ubuntu supported infrastructure, as it is a derivative).

If you can't do this for Solus, you'll have to add support, as described above.

Edit:

just a quick follow up question there're hundreds of packages in base.yml, therefor I was wondering if there is a list of "core" packages I should start with to get me started?

Note that the rosdep database that you are referring to doesn't list 'packages', but keys. The keys map to packages.

I don't know an easy way to recursively list the keys for just system dependencies that a set of ROS packages depends on, but to get a list of what would be installed on a Debian/Ubuntu system, you can use something like the following (I'm using the ros:lunar-ros-core Docker image here because it is convenient, it should also work on a regular ROS install):

$ docker run -it --rm ros:lunar-ros-core \
     rosdep install \
     --simulate \
     --reinstall \
     --ignore-src \
     --from-paths /opt/ros/lunar \
     --rosdistro=lunar

Note that some of the python- packages in that list come from the ROS package repositories (such as catkin_pkg, rospkg and rosdep), so those will not be found in the rosdep db. Most can be installed from pypi (ie: with pip), but if Solus has an official package for those, use that.

For an overview of high-level ROS dependencies and required versions for specific ROS releases, see REP-3, and see REP-142 for info on ROS top-level metapackages.

$ docker run -it --rm ros:lunar-ros-core \
     rosdep keys \
     --ignore-src \
     --from-paths /opt/ros/lunar \
     --rosdistro=lunar

but I don't know what value to put for the OS since Solus isn't built on any other distro.

OS detection is used for (mostly) two things in ROS:

1. determining the name of packages that provide system dependencies (ie: libraries and headers in the C++ case, modules and scripts for Python, etc)
2. figuring out which package manager to use to install those packages

To add support for a new OS, you'll have to figure out how that OS does its package management (or, in the absence of a package concept, installs new software in general).

Ad 1: this comes down to providing mapping rules for rosdep keys to actual package names that Solus recognises. See #q215059 for some info on rosdep and why that is used in ROS, in addition to an example of such a mapping. You'll have to determine which packages map to which rosdep keys and add those to the database. After that, rosdep should know that boost maps to libboost-devel on Solus. It now needs to know how to install it, see below.

Ad 2: does Solus have a package manager? If so, how does it work? Does it use the pkg manager from another OS? If the answer is yes, ROS_OS_OVERRIDE could help. If not, you'll probably have to add a package manager 'plugin' to rosdep so it can communicate with whatever Solus uses.

Concluding: ROS_OS_OVERRIDE can be useful, but only if your target OS is (relatively) similar to an already supported OS (ie: Elementary OS may use the Ubuntu supported infrastructure, as it is a derivative).

If you can't do this for Solus, you'll have to add support, as described above.

Edit:

just a quick follow up question there're hundreds of packages in base.yml, therefor I was wondering if there is a list of "core" packages I should start with to get me started?

Note that the rosdep database that you are referring to doesn't list 'packages', but keys. The keys map to packages.

I don't know an easy way to recursively list the keys for just system dependencies that a set of ROS packages depends on, but to get a list of what would be installed on a Debian/Ubuntu system, you can use something like the following (I'm using the ros:lunar-ros-core Docker image here because it is convenient, it should also work on a regular ROS install):

$ docker run -it --rm ros:lunar-ros-core \
     rosdep install \
     --simulate \
     --reinstall \
     --ignore-src \
     --from-paths /opt/ros/lunar \
     --rosdistro=lunar

Note that ros-core is really the base ROS metapackage (see below), so replace with the image corresponding to the metapackage you'd like to target (I'd start with core or base first though).

See REP-142 for info on ROS top-level metapackages and see REP-3 for an overview of high-level ROS dependencies and required versions for specific ROS releases.

Note: some of the python- packages in that list the output come from the ROS package repositories (such as catkin_pkg, rospkg and rosdep), so those will not be found in the rosdep db. Most can be installed from pypi (ie: with pip), but if Solus has an official package for those, use that.

For an overview of high-level ROS dependencies and required versions for specific ROS releases, see REP-3, and see REP-142 for info on ROS top-level metapackages.

Edit2: I'll add this variant that prints the keys (which might actually make more sense when looking to add support for a new OS to rosdep), but as I mention in my comment below, note that this does not just print a list of system dependencies, but includes ROS packages as well:

$ docker run -it --rm ros:lunar-ros-core \
     rosdep keys \
     --ignore-src \
     --from-paths /opt/ros/lunar \
     --rosdistro=lunar

but I don't know what value to put for the OS since Solus isn't built on any other distro.

OS detection is used for (mostly) two things in ROS:

1. determining the name of packages that provide system dependencies (ie: libraries and headers in the C++ case, modules and scripts for Python, etc)
2. figuring out which package manager to use to install those packages

To add support for a new OS, you'll have to figure out how that OS does its package management (or, in the absence of a package concept, installs new software in general).

Ad 1: this comes down to providing mapping rules for rosdep keys to actual package names that Solus recognises. See #q215059 for some info on rosdep and why that is used in ROS, in addition to an example of such a mapping. You'll have to determine which packages map to which rosdep keys and add those to the database. After that, rosdep should know that boost maps to libboost-devel on Solus. It now needs to know how to install it, see below.

Ad 2: does Solus have a package manager? If so, how does it work? Does it use the pkg manager from another OS? If the answer is yes, ROS_OS_OVERRIDE could help. If not, you'll probably have to add a package manager 'plugin' to rosdep so it can communicate with whatever Solus uses.

Concluding: ROS_OS_OVERRIDE can be useful, but only if your target OS is (relatively) similar to an already supported OS (ie: Elementary OS may use the Ubuntu supported infrastructure, as it is a derivative).

If you can't do this for Solus, you'll have to add support, as described above.

Edit:

just a quick follow up question there're hundreds of packages in base.yml, therefor I was wondering if there is a list of "core" packages I should start with to get me started?

Note that the rosdep database that you are referring to doesn't list 'packages', but keys. The keys map to packages.

I don't know an easy way to recursively list the keys for just system dependencies that a set of ROS packages depends on, but to get a list of what would be installed on a Debian/Ubuntu system, you can use something like the following (I'm (this is essentially #q251732, but I'm using the ros:lunar-ros-core Docker image here because it is convenient, it should also work on a regular ROS install):

$ docker run -it --rm ros:lunar-ros-core \
     rosdep install \
     --simulate \
     --reinstall \
     --ignore-src \
     --from-paths /opt/ros/lunar \
     --rosdistro=lunar

ros-core is really the base ROS metapackage (see below), so replace with the image corresponding to the metapackage you'd like to target (I'd start with core or base first though).

See REP-142 for info on ROS top-level metapackages and see REP-3 for an overview of high-level ROS dependencies and required versions for specific ROS releases.

Note: some of the python- packages in the output come from the ROS package repositories (such as catkin_pkg, rospkg and rosdep), so those will not be found in the rosdep db. Most can be installed from pypi (ie: with pip), but if Solus has an official package for those, use that.

Edit2: I'll add this variant that prints the keys (which might actually make more sense when looking to add support for a new OS to rosdep), but as I mention in my comment below, note that this does not just print a list of system dependencies, but includes ROS packages as well:

$ docker run -it --rm ros:lunar-ros-core \
     rosdep keys \
     --ignore-src \
     --from-paths /opt/ros/lunar \
     --rosdistro=lunar