The decision to remove the concept of stacks, leaving only packages
, , drove the decision to merge the information contained in
both stack.xml and manifest.xml.
The package.xml contains several kinds of information:
- descriptive data (i.e. a description, maintainer)
- dependencies on other ROS and system packages
- meta-information (i.e. the author and website)
- packaging information (i.e. the version)
Instead of modifying the semantics and content of the old files a new
filename is chosen to make it possible to distinguish old and new
packages without parsing the contents of the xml file.
Each package has one package.xml which contains all necessary
data, instead of multiple separate files with semantically grouped
information. Several tools, like the buildfarm and the wiki, need to
use that information. They only need to fetch one file from each
All data are stored in atomic units for automated processing. For
example, names and email addresses are stored separately.
Besides XML, which was used for stack.xml and manifest.xml,
other formats were considered. YAML was investigated extensively
during the Fuerte cycle, because it is easier for humans to read.
Since benchmark results showed YAML parsing in Python to be
ten times slower, the XML format remains.
The allowed package.xml elements are tightly restricted. That
way, tools can reliably detect errors and provide meaningful error
messages should a user misspell any of the tags defined here.
Within the <export> element, tools may define additional tags,
free from those restrictions.
If new top-level tags are needed, the format attribute of the
<package> tag provides a migration path.
Package names are used in various contexts:
- part of a binary package name (i.e. Debian , Fedora )
All ROS package names must be mapped to these conventions without
generating collision. Therefore only lower case letters (a-z),
numbers (0-9) and one delimiting character (_) can be used. The
additional restriction that the first character be a letter is due to
the requirements of some languages for naming packages or namespaces.
The package manifest is an XML file, with restricted syntax.
The only top-level element allowed is <package>. Immediately
subordinate to that are several required or optional elements, defined
here. No other tags are permitted directly under the <package>
The <package> tag is the unique top-level tag in a package.xml
file. All other tags are nested under it.
Specifying the package.xml format being used. If not set, the
default format="1" is assumed. That is the only format
described here. If you are using a different format, please refer
to the relevant specification. REP-0140 will describe format
ROS communications-related packages, including core client
libraries (roscpp, rospy, roslisp) and graph introspection tools
(rostopic, rosnode, rosservice, rosparam).
<author email="firstname.lastname@example.org">Jane Doe</author>
<build_depend version_gte="1.1" version_lt="2.0">genmsg</build_depend>
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 version number of the package in the format MAJOR.MINOR.PATCH
where each part is numeric only.
The description of the package. It can consist of multiple lines and
may contain XHTML. But depending on where the description is used
XML tags and multiple whitespaces might be stripped.
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
A Uniform Resource Locator for the package's website, bug tracker or
It is a good idea to include <url> tags pointing users to these
resources. The website is commonly a wiki page on ros.org where
users can find and update information about the package.
The type should be one of the following identifiers: website
(default), bugtracker or repository.
Declares a rosdep key or ROS package name that this package requires
The build and buildtool dependencies are used to determine
the build order of multiple packages.
All dependencies and relationships may restrict their applicability
to particular versions. For each comparison operator an attribute
can be used. Two of these attributes can be used together to
describe a version range.
The dependency to the package is restricted to versions less than
the stated version number.
The dependency to the package is restricted to versions less or
equal than the stated version number.
The dependency to the package is restricted to a version equal than
the stated version number.
The dependency to the package is restricted to versions greater or
equal than the stated version number.
The dependency to the package is restricted to versions greater than
the stated version number.
Declares a rosdep key or ROS package name that this package needs
either at run-time or as part of some exported build interface.
The <run_depend> declares two different types of package
dependencies. One is for shared libraries, executables, Python
modules, launch scripts and other files required for running your
The second type of <run_depend> is for transitive build
dependencies. A common example is when one of your dependencies
provides a header file included in some header exported by your
package. Even if your package does not use that header when building
itself, other packages depending on your header will require those
transitive dependencies when they are built.
Declares a rosdep key or ROS package name that your package needs for
running its unit tests.
A <test_depend> may not reference any package also declared using
a <build_depend>, <buildtool_depend> or <run_depend>.
Declares a rosdep key or ROS package name with which your package
conflicts. This package and the conflicting package cannot be
installed at the same time. This maps to conflicts for both
dpkg and rpms.
For a detailed explanation how these relationships are used see
Declares a rosdep key or ROS package name that your package replaces.
This maps to Replaces for dpkg and Obsoletes for rpms.
This tag serves as a container for additional information various
packages and subsystems need to embed. To avoid potential collisions
packages must use their package name as their tag name inside the
export block. 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 contains no
This tag indicates the package's build type. If unspecified, the
default is catkin. Typical value is cmake to denote a plain
CMake package, but any string is allowed.
The <build_type> tag may only be specified once.
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:
- Authors are now split into authors and maintainers.
- Multiple people and their emails are specified in separate tags
- Authors are now optional.
- Maintainers must provide an email address.
- At least one maintainer is now required.
- Multiple licenses can now be used, even though a single license per
package is desired.
- Multiple url tags can be specified with type attributes
indicating their meanings.
- The former depend and rosdep have been unified, but also
split into various types of dependencies.
- The export tag:
- The cpp tag has been dropped, it is handled by catkin.
- The roslang tag has been dropped, it is handled by catkin.
- The copyright tag has been dropped.
- The logo tag has been dropped.
- The review tag has been dropped, that information will be
stored on the website of that package.
- The versioncontrol tag has been dropped.
All tools using stack.xml and manifest.xml are updated to work
with package.xml files.
Migration to the new format only affects packages being converted to
catkin. Existing rosbuild packages remain the same. Rosdep
distinguishes between catkin and rosbuild and returns the correct
Additional meta-information can be added within the export tag, as
New features related to the infrastructure can be specified and
integrated using additional tags and attributes, but this requires
introducing a new <package> format number.