您正在阅读的是开发版本的文档。有关最新发布的版本，请访问 Jazzy.
迁移软件包
有两种不同的软件包迁移：
将现有软件包的源代码从 ROS 1 迁移到 ROS 2，目的是使源代码的大部分保持不变或至少相似。例如 插件库 在这种情况下，源代码保存在同一版本库的不同分支中，必要时可在这些分支之间移植通用补丁。
为 ROS 2 实现与 ROS 1 软件包相同或相似的功能，但假设源代码会有很大不同。例如 roscpp 在 ROS 1 和 rclcpp 在 ROS 2 中，它们是独立的软件源，不共享任何代码。
先决条件
在将 ROS 1 软件包迁移到 ROS 2 之前，其所有依赖项都必须在 ROS 2 中可用。
软件包格式版本
ROS 2 不支持软件包规范的格式 1，只支持较新的格式版本（2 及更高）。因此 package.xml 由于 ROS 1 支持所有格式，因此在 ROS 1 软件包中执行转换是安全的。
从软件包格式 1 迁移到 2+
格式 1 和格式 2 之间的差异只影响 package.xml 及其依赖项。 REP-0140 定义了这些差异并提供了其理由。
参见 ROSDEP 文件 了解有关各种标记的更多信息。
<package>；
<package>标记决定使用哪种格式，请像这样更改：
<package 格式="2"；>；
<依赖>；
这是一个新标签，旨在减少不必要的重复。如果您的格式 1 软件包包含
构建依赖关系；动物</build_depend>；
<run_depend>；动物</run_depend>；
应改为
<依赖>；动物依赖</depend>；
在格式 2 中，这相当于
构建依赖关系；动物</build_depend>；
构建_导出_依赖>；动物</build_export_depend>；
执行依赖关系；动物</exec_depend>；
<run_depend>；
不再允许使用该标签。无论在哪里发现，都必须更换：
<run_depend>；动物</run_depend>；
在格式 2 中，这相当于这两个新标签：
构建_导出_依赖>；动物</build_export_depend>；
执行依赖关系；动物</exec_depend>；
如果依赖关系仅在运行时使用，则只有 执行依赖关系； 需要。如果只是为了满足其他软件包的编译依赖而导出，则使用 构建_导出_依赖>；.如果两者都需要，这可能是更好的选择：
<依赖>；动物依赖</depend>；
<test_depend>；
在格式 2 中，该标记可以满足构建依赖项，而不仅仅是执行测试所需的依赖项。与格式 1 不同、 <test_depend>； 现在也可以引用声明为其他类型依赖关系的软件包。
一些仅用于测试的依赖项以前需要 构建依赖关系；现在应该用 <test_depend>；.例如
构建依赖关系；试吃</build_depend>；
成为：
<test_depend>；试吃</test_depend>；
在 CMakeLists.txt 中，确保只在条件测试块中引用测试依赖项：
如果 (构建测试)
查找软件包(试吃 要求)
endif()
<doc_depend>；
该标签定义了构建文档所需的依赖项：
<doc_depend>；源代码</doc_depend>；
<doc_depend>；python3-sphinx</doc_depend>；
这不会创建二进制包依赖关系，除非这些依赖关系也是使用其他依赖关系标记声明的。
依赖关系名称
来自 rosdep 无需更改，因为 ROS 1 和 ROS 2 共享这些内容。
一些发布到 ROS 中的软件包在 ROS 2 中可能有不同的名称，因此可能需要相应地更新依赖关系。
元软件包
ROS 2 并没有为元软件包提供特殊的软件包类型。元软件包仍然可以作为只包含运行时依赖关系的普通软件包存在。从 ROS 1 迁移元软件包时，只需移除 元软件包 />； 标签。请参见 使用变体 元软件包/变体的更多信息。
许可
在 ROS 1 中，我们推荐的许可证是 3 条款 BSD 许可.在 ROS 2 中，我们推荐使用 Apache 2.0 许可.
对于任何新项目，无论是 ROS 1 还是 ROS 2，我们都建议使用 Apache 2.0 许可。
不过，在将代码从 ROS 1 移植到 ROS 2 时，我们不能简单地更改许可证。任何已有的贡献都必须保留现有的许可证。
为此，如果要迁移软件包，我们建议保留现有许可证，并继续根据现有的 OSI 许可证为该软件包做出贡献，我们希望该许可证成为核心元素的 BSD 许可证。
这将使事情清晰易懂。
更改许可证
更改许可证是可能的，但需要联系所有贡献者并获得许可。对于大多数软件包来说，这可能是一项艰巨的工作，不值得考虑。如果软件包的贡献者较少，则可能可行。