Revision history [back]

[..] as far as i can tell, rosdep is a package manager

Almost: it is a meta package manager. Instead of working with packages directly, it asks the package manager of the platform it is run on to install packages for it.

Why was it written, as opposed to using all the other package managers that already exist?

Because it allows you to hide the differences between the various package managers on the various platforms you want to support. This abstraction does not only hide the fact that different platforms use different package managers (with different names, different options, different behaviour, etc), but also the differences in package naming that exist between platforms.

Instead of having to specify all dependencies by name for each and every platform that you want your package to work on (as a developer), you can now use a single key from the rosdep rule db, which is translated into the name of that dependency on a specific platform. The platform's package manager is then asked to check for / install that name.

Without this abstraction, package developers would need to lookup the name of system dependencies for every platform they'd wish to support, and package manifests would have to contain that information. Additionally, extending ROS support to a new platform would require updating all package manifests to add the names of all the system dependencies existing packages use. Even for relatively small numbers of packages, this is impractical (if not infeasible). With rosdep, we 'only' need to add new mappings to the db, and the system takes care of the rest.

As a random example, the following are the mappings for apr (from rosdep/base.yaml):

apr:
  arch: [apr, apr-util]
  cygwin: [libapr1, libaprutil1]
  debian: [libapr1-dev, libaprutil1-dev]
  fedora: [apr-devel, apr-util]
  freebsd: [builtin]
  gentoo: [dev-libs/apr, dev-libs/apr-util]
  macports: [apr, apr-util]
  opensuse: [libapr1, libapr-util1]
  rhel: [apr-devel, apr-util]
  ubuntu: [libapr1-dev, libaprutil1-dev]

I picked this randomly from the list, but I think it illustrates nicely how many different names there can be for a single dependency.

[..] as far as i can tell, rosdep is a package manager

Almost: it is a meta package manager. Instead of working with packages directly, it asks the package manager of the platform it is run on to install packages for it.

Why was it written, as opposed to using all the other package managers that already exist?

Because it allows you to hide the differences between the various package managers on the various platforms you want to support. This abstraction does not only hide the fact that different platforms use different package managers (with different names, different options, different behaviour, etc), but also the differences in package naming that exist between platforms.

Instead of having to specify all dependencies by name for each and every platform that you want your package to work on (as a developer), you can now use a single key from the rosdep rule db, which is translated into the name of that dependency on a specific platform. The platform's package manager is then asked to check for / install that name.

Without this abstraction, package developers would need to lookup the name of system dependencies for every platform they'd wish to support, and package manifests would have to contain that information. Additionally, extending ROS support to a new platform would require updating all package manifests to add the names of all the system dependencies existing packages use. Even for relatively small numbers of packages, this is impractical (if not infeasible). With rosdep, we 'only' need to add new mappings to the db, and the system takes care of the rest.

As a random example, the following are the mappings for apr (from rosdep/base.yaml):

apr:
  arch: [apr, apr-util]
  cygwin: [libapr1, libaprutil1]
  debian: [libapr1-dev, libaprutil1-dev]
  fedora: [apr-devel, apr-util]
  freebsd: [builtin]
  gentoo: [dev-libs/apr, dev-libs/apr-util]
  macports: [apr, apr-util]
  opensuse: [libapr1, libapr-util1]
  rhel: [apr-devel, apr-util]
  ubuntu: [libapr1-dev, libaprutil1-dev]

I picked this randomly from the list, but I think it illustrates nicely how many different names there can be for a single dependency.

tl;dr: because synaptic doesn't work on OSX (fi), and dependency foo may be named foo-dev-1.2.3 on one platform, but libfoo-bar on another. rosdep hides those differences.differences. See also the introductory note in the documentation.

[..] as far as i can tell, rosdep is a package manager

Almost: it is a meta package manager. Instead of working with packages directly, it asks the package manager of the platform it is run on to install packages for it.

Why was it written, as opposed to using all the other package managers that already exist?

Because it allows you to hide the differences between the various package managers on the various platforms you want to support. This abstraction does not only hide the fact that different platforms use different package managers (with different names, different options, different behaviour, etc), but also the differences in package naming that exist between platforms.

Instead of having to specify all dependencies by name for each and every platform that you want your package to work on (as a developer), you can now use a single key from the rosdep rule db, which is translated into the name of that dependency on a specific platform. The platform's package manager is then asked to check for / install that name.

Without this abstraction, package developers would need to lookup the name of system dependencies for every platform they'd wish to support, and package manifests would have to contain that information. Additionally, extending ROS support to a new platform would require updating all package manifests to add the names of all the system dependencies existing packages use. Even for relatively small numbers of packages, this is impractical (if not infeasible). With rosdep, we 'only' need to add new mappings to the db, and the system takes care of the rest.

As a random example, the following are the mappings for apr (from rosdep/base.yaml):

apr:
  arch: [apr, apr-util]
  cygwin: [libapr1, libaprutil1]
  debian: [libapr1-dev, libaprutil1-dev]
  fedora: [apr-devel, apr-util]
  freebsd: [builtin]
  gentoo: [dev-libs/apr, dev-libs/apr-util]
  macports: [apr, apr-util]
  opensuse: [libapr1, libapr-util1]
  rhel: [apr-devel, apr-util]
  ubuntu: [libapr1-dev, libaprutil1-dev]

I picked this randomly from the list, but I think it illustrates nicely how many different names there can be for a single dependency.

tl;dr: because synaptic doesn't work on OSX (fi), and dependency foo may be named foo-dev-1.2.3 on one platform, but libfoo-bar on another. rosdep hides those differences. See also the introductory note in the documentation.

[..] as far as i can tell, rosdep is a package manager

Almost: it is a meta package manager. Instead of working with packages directly, it asks the package manager of the platform it is run on to install packages for it.for it. So instead of working with packages, it works with package managers (that work with packages).

Why was it written, as opposed to using all the other package managers that already exist?

Because it allows you to hide the differences between the various package managers on the various platforms you want to support. This abstraction does not only hide the fact that different platforms use different package managers (with different names, different options, different behaviour, etc), but also the differences in package naming that exist between platforms.

Instead of having to specify all dependencies by name for each and every platform that you want your package to work on (as a developer), you can now use a single key from the rosdep rule db, which is translated into the name of that dependency on a specific platform. The platform's package manager is then asked to check for / install that name.

Without this abstraction, package developers would need to lookup the name of system dependencies for every platform they'd wish to support, and package manifests would have to contain that information. Additionally, extending ROS support to a new platform would require updating all package manifests to add the names of all the system dependencies existing packages use. Even for relatively small numbers of packages, this is impractical (if not infeasible). With rosdep, we 'only' need to add new mappings to the db, and the system takes care of the rest.

As a random example, the following are the mappings for apr (from rosdep/base.yaml):

apr:
  arch: [apr, apr-util]
  cygwin: [libapr1, libaprutil1]
  debian: [libapr1-dev, libaprutil1-dev]
  fedora: [apr-devel, apr-util]
  freebsd: [builtin]
  gentoo: [dev-libs/apr, dev-libs/apr-util]
  macports: [apr, apr-util]
  opensuse: [libapr1, libapr-util1]
  rhel: [apr-devel, apr-util]
  ubuntu: [libapr1-dev, libaprutil1-dev]

I picked this randomly from the list, but I think it illustrates nicely how many different names there can be for a single dependency.

tl;dr: because synaptic doesn't work on OSX (fi), and dependency foo may be named foo-dev-1.2.3 on one platform, but libfoo-bar on another. rosdep hides those differences. See also the introductory note in the documentation.

[..] as far as i can tell, rosdep is a package manager

Almost: it is a meta package manager. Instead of working with packages directly, it asks the package manager of the platform it is run on to install packages for it. So instead of working with packages, it works with package managers (that work with packages).

Why was it written, as opposed to using all the other package managers that already exist?

Because it allows you to hide the differences between the various package managers on the various platforms you want to support. This abstraction does not only hide the fact that different platforms use different package managers (with different names, different options, different behaviour, etc), but also the differences in package naming that exist between platforms.

Instead of having to specify all dependencies by name for each and every platform that you want your package to work on (as a developer), you can now use a single key from the rosdep rule db, which is translated into the name of that dependency on a specific platform. The platform's package manager is then asked to check for / install that name.

Without this abstraction, package developers would need to lookup the name of system dependencies for every platform they'd wish to support, and package manifests would have to contain that information. Additionally, extending ROS support to a new platform would require updating all package manifests to add the names of all the system dependencies existing packages use. Even for relatively small numbers of packages, this is impractical (if not infeasible). With rosdep, we 'only' need to add new mappings to the db, and the system takes care of the rest.

As a random example, the following are the mappings for apr (from rosdep/base.yaml):

apr:
  arch: [apr, apr-util]
  cygwin: [libapr1, libaprutil1]
  debian: [libapr1-dev, libaprutil1-dev]
  fedora: [apr-devel, apr-util]
  freebsd: [builtin]
  gentoo: [dev-libs/apr, dev-libs/apr-util]
  macports: [apr, apr-util]
  opensuse: [libapr1, libapr-util1]
  rhel: [apr-devel, apr-util]
  ubuntu: [libapr1-dev, libaprutil1-dev]

I picked this randomly from the list, but I think it illustrates nicely how many different names there can be for a single dependency.

boost:
  [..]
  ubuntu:
  [..]
    natty:
      apt:
        packages: [libboost1.42-all-dev]
    oneiric:
      apt:
        packages: [libboost1.46-all-dev]
    precise:
      apt:
        packages: [libboost-all-dev]
  [..]