The package name must start with a letter and contain only lowercase
alphabetic, numeric or underscore characters . The package name
should be unique within the ROS community. It may differ from the
folder name into which it is checked out, but that is not recommended.
The following recommended exemptions apply, which are optional for
- Dashes may be permitted in package names. This is to support
maintaining a consistent dependency name when transitioning back
and forth between a system dependency and in-workspace package,
since many rosdep keys contain dashes (inherited from the
- In support of some legacy packages, capital letters may also be
accepted in the package name, with a validation warning.
The name of the person maintaining the package. All packages require
a maintainer. For orphaned packages see below.
Email address of the maintainer.
An orphaned package is one with no current maintainer.
Orphaned packages should use the following maintainer information to
guide volunteers how they can claim maintainership:
<maintainer email="email@example.com">Unmaintained see http://wiki.ros.org/MaintenanceGuide#Claiming_Maintainership</maintainer>
Name of license for this package, e.g. BSD, GPL, LGPL. In order to
assist machine readability, only include the license name in this tag.
For multiple licenses multiple separate tags must be used. A package
will have multiple licenses if different source files have different
licenses. Every license occurring in the source files should have
a corresponding <license> tag. For any explanatory text about
licensing caveats, please use the <description> tag.
Most common open-source licenses are described on the
Commonly used license strings:
- Apache 2.0
- Boost Software License
- Mozilla Public License Version 1.1
This tag serves as a container for additional information various
packages and subsystems need to embed. To avoid potential collisions,
an export tag should have the same name as the package which is meant
to process it. The content of that tag is up to the package to define
Existing rosbuild export tags for tools using pluginlib remain
unchanged. For example, a package which implements an rviz plugin
might include this:
The following are some tags used within an <export> for various
package and message generation tasks.
This empty tag indicates that your package produces no
architecture-specific files once built.
That information is intended for allowing optimization of packaging.
Specifying <architecture_independent/> is recommended for
metapackages and for packages defining only ROS messages and services.
Python-only packages are reasonable candidates, too.
It is not appropriate for any package which compiles C or C++ code.
Be sure to remove this tag if some subsequent update adds
architecture-dependent targets to a formerly independent package.
Various tools use this tag to determine how to handle a package. It
was defined in REP-0134 , which currently specifies only two
If no <build_type> is provided, catkin is assumed.
When the build type is cmake, the package is handled as a
non-catkin CMake project. It cannot be included in a normal catkin
workspace, but can instead use catkin_make_isolated, which
configures and builds a different kind of workspace in which
cmake, make, and make install are invoked separately for
each package. See REP-0134 for details.
Further build types may eventually be defined, such as: "make",
"autotools", "rosbuild", or "custom".
This tag indicates that your package is deprecated, enabling tools to
notify users about that fact. The tag may be empty or may optionally
contain an arbitrary text providing user more information about the
This package will be removed in ROS Hydro. Instead, use package
FOO, which provides similar features with a different API.
The content defines the identifier for the language bindings
generated by this package, i.e. in gencpp this is set to cpp: