Seems like problem is due to ament_target_dependencies.cmake.

While debugging same problem with ros2/rosbag2#687:
Having ament_target_dependencies called like

ament_target_dependencies(${PROJECT_NAME}
  rcpputils
  rosbag2_compression
  zstd)

this code executed(link):

if(NOT ARG_INTERFACE)
  target_compile_definitions(${target}
    ${required_keyword} ${definitions})
  # the interface include dirs must be ordered
  set(interface_include_dirs)
  foreach(interface ${interfaces})
    get_target_property(_include_dirs ${interface} INTERFACE_INCLUDE_DIRECTORIES)
    if(_include_dirs)
      list_append_unique(interface_include_dirs ${_include_dirs})
    endif()
  endforeach()
  ament_include_directories_order(ordered_interface_include_dirs ${interface_include_dirs})
  # the interface include dirs are used privately to ensure proper order
  # and the interfaces cover the public case
  target_include_directories(${target} ${system_keyword}
    PRIVATE ${ordered_interface_include_dirs})
endif()

with interfaces set to list rosbag2_compression;zstd_vendor;rcpputils.

INTERFACE_INCLUDE_DIRECTORIES of these targets are populated with values:

/home/hexonxons/ros/ws/install/rosbag2_compression/include
/home/hexonxons/ros/ws/install/zstd_vendor/include
/opt/ros/foxy/include

accordingly. /home/hexonxons/ros/ws/ is my local workspace.

rosbag2_compression depends on rosbag2_cpp, but there is no /home/hexonxons/ros/ws/install/rosbag2_cpp/include path in that list, cuz INTERFACE_INCLUDE_DIRECTORIES property is populated by target_include_directories command according to documentation

Also, according to same documentation:

The INSTALL_INTERFACE of the INTERFACE_INCLUDE_DIRECTORIES is only suitable for specifying the required include directories for headers provided with the target itself, not those provided by the transitive dependencies listed in its INTERFACE_LINK_LIBRARIES target property. Those dependencies should themselves be targets that specify their own header locations in INTERFACE_INCLUDE_DIRECTORIES.

So fast idea for this to work we need to recursively get dependencies from INTERFACE_LINK_LIBRARIES property and populate interface_include_dirs with INTERFACE_INCLUDE_DIRECTORIES property of each dependency. This needs to be investigated deeper to find out if this is right fix

@hexonxons Thanks for posting your investigation!

The relevant ament_cmake code was added in ament/ament_cmake#260 to fix a similar issue related to overlays (ros2/geometry2#268). (I had forgotten about it even though I reviewed it 😅).

I think your assessment is correct. The current code only orders include directories for the declared dependencies, it is not considering transitive dependencies. Though, with my current understanding of CMake, I agree with this comment, and CMake should already be able to handle the include directories of the transitive dependencies for us.

I tried the applying the following change:

--- a/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake
+++ b/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake
@@ -127,19 +127,7 @@ function(ament_target_dependencies target)
     if(NOT ARG_INTERFACE)
       target_compile_definitions(${target}
         ${required_keyword} ${definitions})
-      # the interface include dirs must be ordered
-      set(interface_include_dirs)
-      foreach(interface ${interfaces})
-        get_target_property(_include_dirs ${interface} INTERFACE_INCLUDE_DIRECTORIES)
-        if(_include_dirs)
-          list_append_unique(interface_include_dirs ${_include_dirs})
-        endif()
-      endforeach()
-      ament_include_directories_order(ordered_interface_include_dirs ${interface_include_dirs})
-      # the interface include dirs are used privately to ensure proper order
-      # and the interfaces cover the public case
-      target_include_directories(${target} ${system_keyword}
-        PRIVATE ${ordered_interface_include_dirs})
+      target_link_libraries(${target} ${interfaces})

This gives us control over the order that include directories are passed to the compiler. For example, if I make the following change to my reproduction, then I can successfully compile the packages:

--- a/overlay/src/package_d/CMakeLists.txt
+++ b/overlay/src/package_d/CMakeLists.txt
@@ -13,10 +13,10 @@ add_library(${PROJECT_NAME}
   src/package_d.cpp
 )
 ament_target_dependencies(${PROJECT_NAME}
-  package_b
   # Targeting package_c causese underlay path to appear before overlay
   # The underlay contains an older version of package_a that package_b is not expecting
   package_c
+  package_b

I'm not sure if this is a desirable solution since it makes ament_target_dependencies sensitive to the order of it's arguments.

It seems like we need a way to detect if a dependency is in the overlay or not. Then we could order the target dependencies such that dependencies in the same overlay as the package being built appear first.

@jacobperron Yep, cmake is handling include directories of the transitive dependencies.
In your case while compiling with colcon build --ament-cmake-args -DCMAKE_EXPORT_COMPILE_COMMANDS=ON and having ament_target_dependencies.cmake changed:

Compile commands for package_d:

• package_b goes before package_c:

{
  "directory": "/home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/build/package_d",
  "command": "/usr/bin/c++   -isystem /home/hexonxons/ros/ws/src/overlay_bug_reproduction/underlay/install/include -isystem /home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/install/package_c/include -isystem /home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/install/package_a/include    -Wall -Wextra -Wpedantic -o CMakeFiles/package_d.dir/src/package_d.cpp.o -c /home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/src/package_d/src/package_d.cpp",
  "file": "/home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/src/package_d/src/package_d.cpp"
}

• package_b goes after package_c:

{
  "directory": "/home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/build/package_d",
  "command": "/usr/bin/c++   -isystem /home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/install/package_c/include -isystem /home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/install/package_a/include -isystem /home/hexonxons/ros/ws/src/overlay_bug_reproduction/underlay/install/include    -Wall -Wextra -Wpedantic -o CMakeFiles/package_d.dir/src/package_d.cpp.o -c /home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/src/package_d/src/package_d.cpp",
  "file": "/home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/src/package_d/src/package_d.cpp"
}

So in first case -isystem /home/hexonxons/ros/ws/src/overlay_bug_reproduction/underlay/install/include goes first cuz it is in package_b INTERFACE_INCLUDE_DIRECTORIES property and you links it first.
Next goes -isystem /home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/install/package_c/include -isystem /home/hexonxons/ros/ws/src/overlay_bug_reproduction/overlay/install/package_a/include, cuz it is in INTERFACE_INCLUDE_DIRECTORIES property of project_c:

ament_target_dependencies(${PROJECT_NAME}
  package_a
)
target_include_directories(${PROJECT_NAME}
  PUBLIC
  $<INSTALL_INTERFACE:include>
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
)

How did I suggest to fix:

if(NOT ARG_INTERFACE)
  target_compile_definitions(${target}
    ${required_keyword} ${definitions})
  # the interface include dirs must be ordered
  set(interface_include_dirs)
  set(interface_libraries)
  foreach(interface ${interfaces})
     set(current_interface_include_dirs)
     set(current_interface_libraries)
     ament_get_recursive_properties(current_interface_include_dirs current_interface_libraries ${interface})
     message(WARNING "interface_include_dirs for target ${interface}: ${current_interface_include_dirs}")
     message(WARNING "interface_libraries for target ${interface}: ${current_interface_libraries}")
     list_append_unique(interface_include_dirs "${current_interface_include_dirs}")
     list_append_unique(interface_libraries "${current_interface_libraries}")
  endforeach()
  message(WARNING "All interface_include_dirs: ${interface_include_dirs}")
  message(WARNING "All interface_libraries: ${interface_libraries}")
  ament_include_directories_order(ordered_interface_include_dirs ${interface_include_dirs})
  # the interface include dirs are used privately to ensure proper order
  # and the interfaces cover the public case
  target_include_directories(${target} ${system_keyword}
    PRIVATE ${ordered_interface_include_dirs})
endif()

You could try to build your packages and see debugging warning messages :)

But still that is very strange way of doing cmake job. In non-ros cmake projects if you have package_a depending on package_b depending on package_c and want to

• Build package_b
• export CMAKE_PREFIX_PATH to package_b
• Build package_a
• export CMAKE_PREFIX_PATH to package_a
• Build package_c

So you will get package_b linked to system wide installed package_a and package_d linked to system wide installed package_a. If you also export LD_LIBRARY_PATH to local installed package_a you will get package_d build with system-wide installed package_a headers, but in runtime it will load shared lib of package_a :)

So I prefer to build full ROS repo in case of building overlay workspaces. In this case target_link_libraries(${target} ${interfaces}) might be sufficient

I pushed an experimental patch that relies on target_link_libraries (ament/ament_cmake@a284c00), but it has a brittle heuristic for checking if targets are from the same overlay or not. We could instead do something based on the AMENT_PREFIX_PATH like ament_include_directories_order does, which might be a bit better. But I'm still not convinced it is much better than your proposed patch. In general, you are right that building all packages is safer than attempting an overlay.

@jacobperron Could we just use target_link_libraries? Overlay should work properly if you are building all packages in repo without skipping(e.g don't skip any package from rosbag2 repo if building rosbag2 repo in overlay) and maintainers declare package dependencies properly.

Otherwise your case is a quite "pro" case when you are trying to build not one, but several repos of ros packages while skipping dependencies in between (package_b).

I will try to check if target_link_libraries fixes problem for rosbag2 tomorrow

Nah, it wonk work so easy :(

Could we just use target_link_libraries?

IIUC, this is what was happening before ament/ament_cmake#260 (ie. just try reverting ament/ament_cmake#260 and see what happens). I think we still need to worry about the order of targets passed to target_link_libraries. Currently ament_target_dependencies is trying to handle the ordering for the user (but failing in some cases). Alternatively, we could say that it's the users responsibility to order dependencies passed to ament_target_dependencies "correctly", but I don't think the order is obvious and depends on workspace layout.

This ticket is about sorting include directories based on the order workspaces are overlayed, but that's not the only problem with overriding packages.
Any non-leaf package must only be overriden by an API and ABI compatible version or the runtime behavior is undefined.

Include directory search order matters anytime headers with the same name can be found in different directories.
Usually this is only a problem when overriding a package in a merged underlay workspace.
The underlay's include directory might be searched first depending on the order of include directories given in CMake.
Depending on the differences with the overlay's include, it could cause build failures or undefined behavior at runtime.

Here are few types of solutions that could address the include directory search order problem.

Option 1: Reorder the include directories in CMake (ROS 1 does this)

Catkin solved this with find_package(catkin REQUIRED COMPONENTS pkg_a pkg_b).
That calls find_package() pkg_a and pkg_b, then it appends their *_INCLUDE_DIRS into the combined variable catkin_INCLUDE_DIRS.
Finally it orders the directories in that variable based on the order of workspaces sourced.
It knows about workspaces using a combination of CMAKE_PREFIX_PATH and marker files.
This mostly works, except quite a few packages don't use it or use it incorrectly.

Something that makes this kind of solution harder in ROS 2 is the separation of the build tool (colcon) and the build system (CMake).
Instead of one kind of workspace (catkin), there are two kinds of workspaces a ROS 2 package would need to be made aware of: ament and colcon.
The debian packages for ROS 2 install into an ament workspace.
It is created by ros_workspace using scripts from ament_package.
From-source builds and packaging job archives are colcon workspaces.
ROS 2 packages need to have knowledge of both to solve this problem the same way.

Another reason this is hard is ROS 2 uses modern CMake targets instead of old-style CMake standard variables.
The old-style CMake standard variable *_INCLUDE_DIRS contains a list of directories, including the include directories from all transitive dependencies.
Modern CMake targets have an INTERFACE_INCLUDE_DIRECTORIES target property instead, and its dependencies are targets listed in INTERFACE_LINK_LIBRARIES.
Getting all include directories requires traversing a tree of targets and querying their parameters.

Something that makes this very hard is INTERFACE_INCLUDE_DIRECTORIES may contain generator expressions.
Even if an ament_cmake macro was made to traverse the tree of dependencies, read INTERFACE_INCLUDE_DIRECTORIES from each target, and overwrite the INCLUDE_DIRECTORIES property of the target with the sorted list, it cannot resolve and sort generator expressions.
The include directory search order could still be wrong depending on how any generator expressions got resolved.

Another thing that makes this kind of solution hard is it would almost certainly require all existing ROS packages to update their CMake code to use it.
Every package in the overlay workspace where at least one package is being overridden must implement this solution (whatever it looks like, ament_target_dependencies() or otherwise) or the include directory search order may be wrong.

I don't think this option is worth the effort in ROS 2.

Option 2: Make the include directories be installed to another prefix?

Currently ROS 2 packages install headers include, meaning, in a merged workspace (/opt/ros/foxy) all packages have the same include directory (/opt/ros/foxy/include).
The include #include <rclcpp/rclcpp.hpp> would be found at /opt/ros/foxy/include/rclcpp/rclcpp.hpp.
If they add another package specific directory, like include/${PROJECT_NAME}, then the include directory will become /opt/ros/foxy/include/rclcpp/.
That would prevent includes from other packages in a merged workspace to be found.

# Instead of this
# install(DIRECTORY include/ DESTINATION include)
# Do this
install(DIRECTORY include/ DESTINATION include/${PROJECT_NAME})

This would require all packages in the underlay workspace to implement it.
It would also mean updating REP 122.

This alone would bring overriding in ROS 2 to a similar state as ROS 1, but without requiring packages to know about workspaces.
This option seems like much less work for a similar result as option 1.

Option 3: Can the build tool (colcon) or workspace hide duplicate includes with sandboxing?

What if colcon detected when overriding packages, and made only the non-overridden packages from the underlay available?
Colcon would have to be able to know what files in an underlay belonged to which package.
When the underlay workspace is an isolated one, that's pretty much what happens already.
For merged underlay workspaces that's very hard.

Maybe when overriding a package from an ament workspace /opt/ros/... colcon could use dpkg -L ros-...-... to list the files for a package in a ROS distribution, and symlink them to a hidden underlay that then gets sourced.
For any underlay that is a merged colcon workspace (like the ROS 2 packaging job archives), colcon would need a different mechanisim to determine what files belong to a package.
Maybe colcon could build all packages in a sandbox using a tool like sandboxfs, create a manifest of all the new files in the sandbox, and use that manifest when overlaying this workspace?

That sounds hard to do on one platform, let alone all of the supported ones.
Even bazel hasn't figured out sandboxing on windows.
Something smaller in scope, like a script that symlinks a new underlay from /opt/ros/... based on the package to override and the debian package contents could be doable.
Solving overriding from the merged colcon workspaces provided by the packaging jobs seems to be the hardest part.

Option 4: Discourage overriding packages by warning or erroring about it?

Another option is to make colcon warn or error when a package is being overridden.
A developer could choose to ignore it and attempt to override packages anyways.
There are two things I think are worth warning about:

At build time (when colcon build or colcon test is called)

• If any package is overridden, warn about include directory search order issues
• if any non-leaf package is overridden, warn that it must be API/ABI compatible

Maybe a user could silence warnings or allow building to proceed with a CLI flag like --allow-overriding pkg_a.

At run time (when sourcing an overlay workspace)

• if any non-leaf package is overridden, warn that it must be API/ABI compatible

Maybe there's no way to silence this warning, but it wouldn't block the user.

Personally I like this option the most because it gives an opportunity to warn about API/ABI issues.
It seems easy to me to miss those and face undefined behavior at runtime.

@sloretz Thanks for laying out those options!

IIUC, ament/ament_cmake#343 proposes something close to option 1 (though I guess it's missing a recursive traversal of target dependencies).

IMO, requiring calls to ament_target_dependencies (option 1) or installing headers into a different prefix (option 2) are not terrible options from a user standpoint. Inevitably there will be cases where packages don't follow suite, but that's their prerogative.

Option 3 is intriguing but sounds like the most challenging to implement IMO.

+1 for option 4, regardless of whether another option is implemented since I don't see how we can do anything else reasonable to guard against ABI incompatibilities in the non-leaf package case.

+1 for option 4, regardless of whether another option is implemented since I don't see how we can do anything else reasonable to guard against ABI incompatibilities in the non-leaf package case.

Yeah, totally agreed; regardless of what else we do, I think we should implement option 4 as a warning (maybe with a flag to disable).

See colcon/colcon-core#449 and colcon/colcon-ros#129 for an implementation of option 4. It warns when colcon build is called and adds a flag to disable it.

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2021-10-28/22947/1

I agree with the concern about non-leaf packages leading to undefined behaviour, but once a warning is in place for those I think that the leaf package use case needs to be fixed urgently. This bug breaks a common and intended workflow, and I regularly lose time to the confusing compiler errors it can cause or having to work around it.

Alternatively, if we're going to just not support overlaying packages then we should explicitly disable it by having colcon check for the same package name occurring multiple times across all sourced workspaces and throwing an error if it finds one.

I think that the leaf package use case needs to be fixed urgently

I'm not sure it needs to be fixed urgently as it's the easiest to work around. If the leaf package is uninstalled then the issue goes away.

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2021-11-18/23209/1

I'm not sure it needs to be fixed urgently as it's the easiest to work around. If the leaf package is uninstalled then the issue goes away.

If you're installing from binary debs, which is when this problem occurs most often due to the merged install space, then uninstalling the leaf package is often not possible. In my case the leaf packages are all rosbag2 packages, which can't be uninstalled without removing the ros-X-desktop package. The problem is that they are leaf packages at compile time but not in the debs.

In my case the leaf packages are all rosbag2 packages, which can't be uninstalled without removing the ros-X-desktop package.

Uninstalling is still possible, but I see how that makes it inconvenient. I tried uninstalling one of the rosbag2 debs and saw the other ros-rolling-* packages automatically installed with ros-rolling-desktop were still installed, but in a state where apt autoremove would uninstall them. A workaround for that is to mark the dependencies of ros-rolling-desktop as manually installed.

$ apt-cache depends ros-rolling-desktop | awk '/Depends/ {print $2}' | xargs apt-mark auto

These are the packages that install headers and are depended on by ros-rolling-desktop. Along with colcon warning (colcon/colcon-core#449), implementing option 2 in these packages seems good enough to resolve this ticket.

$ dpkg -S /opt/ros/rolling/include/ | sed 's/, /\n/g' | sed 's/:.*$//'
ros-rolling-turtlesim
ros-rolling-map-msgs
ros-rolling-rviz-default-plugins
ros-rolling-interactive-markers
ros-rolling-rosbag2-interfaces
ros-rolling-rviz-rendering
ros-rolling-laser-geometry
ros-rolling-rosbag2-cpp
ros-rolling-rosbag2-compression-zstd
ros-rolling-pcl-msgs
ros-rolling-robot-state-publisher
ros-rolling-tf2-msgs
ros-rolling-message-filters
ros-rolling-kdl-parser
ros-rolling-tf2-eigen
ros-rolling-tf2-ros
ros-rolling-tf2
ros-rolling-pluginlib
ros-rolling-rosbag2-transport
ros-rolling-rcl-lifecycle
ros-rolling-keyboard-handler
ros-rolling-lifecycle-msgs
ros-rolling-pybind11-vendor
ros-rolling-example-interfaces
ros-rolling-trajectory-msgs
ros-rolling-tf2-eigen-kdl
ros-rolling-stereo-msgs
ros-rolling-nav-msgs
ros-rolling-rclcpp-lifecycle
ros-rolling-joy
ros-rolling-diagnostic-msgs
ros-rolling-std-srvs
ros-rolling-geometry-msgs
ros-rolling-tf2-kdl
ros-rolling-pendulum-msgs
ros-rolling-angles
ros-rolling-composition-interfaces
ros-rolling-actionlib-msgs
ros-rolling-class-loader
ros-rolling-rcl-action
ros-rolling-rclcpp
ros-rolling-rosgraph-msgs
ros-rolling-statistics-msgs
ros-rolling-image-transport
ros-rolling-urdf-parser-plugin
ros-rolling-libstatistics-collector
ros-rolling-rosidl-typesupport-fastrtps-c
ros-rolling-fastrtps
ros-rolling-rcl
ros-rolling-rmw-dds-common
ros-rolling-rqt-gui-cpp
ros-rolling-cyclonedds
ros-rolling-rosidl-typesupport-fastrtps-cpp
ros-rolling-iceoryx-utils
ros-rolling-tf2-geometry-msgs
ros-rolling-urdfdom-headers
ros-rolling-libyaml-vendor
ros-rolling-rosidl-typesupport-c
ros-rolling-action-msgs
ros-rolling-iceoryx-binding-c
ros-rolling-rcl-yaml-param-parser
ros-rolling-action-tutorials-interfaces
ros-rolling-unique-identifier-msgs
ros-rolling-rosidl-typesupport-introspection-c
ros-rolling-rosidl-runtime-cpp
ros-rolling-rmw
ros-rolling-rosidl-typesupport-interface
ros-rolling-rosbag2-compression
ros-rolling-shared-queues-vendor
ros-rolling-rosbag2-storage-default-plugins
ros-rolling-rosbag2-storage
ros-rolling-visualization-msgs
ros-rolling-logging-demo
ros-rolling-image-tools
ros-rolling-std-msgs
ros-rolling-shape-msgs
ros-rolling-rcl-interfaces
ros-rolling-urdfdom
ros-rolling-rclcpp-components
ros-rolling-rcpputils
ros-rolling-rosidl-runtime-c
ros-rolling-rcutils
ros-rolling-iceoryx-posh
ros-rolling-builtin-interfaces
ros-rolling-ament-index-cpp
ros-rolling-console-bridge-vendor
ros-rolling-tlsf-cpp
ros-rolling-rcl-logging-interface
ros-rolling-tlsf
ros-rolling-rosidl-typesupport-introspection-cpp
ros-rolling-rosidl-typesupport-cpp
ros-rolling-qt-gui-cpp
ros-rolling-rqt-image-view
ros-rolling-urdf
ros-rolling-image-geometry
ros-rolling-depthimage-to-laserscan
ros-rolling-rmw-fastrtps-cpp
ros-rolling-foonathan-memory-vendor
ros-rolling-tracetools
ros-rolling-rviz-common
ros-rolling-rttest
ros-rolling-fastcdr
ros-rolling-intra-process-demo
ros-rolling-resource-retriever
ros-rolling-tf2-sensor-msgs
ros-rolling-teleop-twist-joy
ros-rolling-zstd-vendor
ros-rolling-tf2-bullet
ros-rolling-sensor-msgs
ros-rolling-orocos-kdl
ros-rolling-cv-bridge
ros-rolling-rclcpp-action
ros-rolling-pcl-conversions
ros-rolling-rmw-fastrtps-shared-cpp

Another command to get the sources for repos that will likely need to be edited - except pcl_msgs. All of the msgs packages probably need edits to the C/C++ generator packages instead.

dpkg -S /opt/ros/rolling/include/ | sed 's/, /\n/g' | sed 's/:.*$//' | sed 's/ros-rolling-//' | sed 's/-/_/g' | xargs echo | xargs rosinstall_generator --rosdistro rolling --format repos --upstream
The following repositories with an unknown upstream will be ignored: pcl_msgs
repositories:
  ament_index:
    type: git
    url: https://github.com/ament/ament_index.git
    version: 1.3.0
  angles:
    type: git
    url: https://github.com/ros/angles.git
    version: 1.12.4
  class_loader:
    type: git
    url: https://github.com/ros/class_loader.git
    version: 2.1.2
  common_interfaces:
    type: git
    url: https://github.com/ros2/common_interfaces.git
    version: 3.0.0
  console_bridge_vendor:
    type: git
    url: https://github.com/ros2/console_bridge_vendor.git
    version: 1.3.2
  cyclonedds:
    type: git
    url: https://github.com/eclipse-cyclonedds/cyclonedds.git
    version: 0.8.0
  demos:
    type: git
    url: https://github.com/ros2/demos.git
    version: 0.17.0
  depthimage_to_laserscan:
    type: git
    url: https://github.com/ros-perception/depthimage_to_laserscan.git
    version: 2.3.1
  example_interfaces:
    type: git
    url: https://github.com/ros2/example_interfaces.git
    version: 0.9.2
  fastcdr:
    type: git
    url: https://github.com/eProsima/Fast-CDR.git
    version: 1.0.20
  fastrtps:
    type: git
    url: https://github.com/eProsima/Fast-DDS.git
    version: 2.3.4
  foonathan_memory_vendor:
    type: git
    url: https://github.com/eProsima/foonathan_memory_vendor.git
    version: 1.2.0
  geometry2:
    type: git
    url: https://github.com/ros2/geometry2.git
    version: 0.19.0
  iceoryx:
    type: git
    url: https://github.com/eclipse-iceoryx/iceoryx.git
    version: 1.0.0
  image_common:
    type: git
    url: https://github.com/ros-perception/image_common.git
    version: 3.1.0
  interactive_markers:
    type: git
    url: https://github.com/ros-visualization/interactive_markers.git
    version: 2.3.0
  joystick_drivers:
    type: git
    url: https://github.com/ros-drivers/joystick_drivers.git
    version: 3.0.0
  kdl_parser:
    type: git
    url: https://github.com/ros/kdl_parser.git
    version: 2.5.0
  keyboard_handler:
    type: git
    url: https://github.com/ros-tooling/keyboard_handler.git
    version: 0.0.2
  laser_geometry:
    type: git
    url: https://github.com/ros-perception/laser_geometry.git
    version: 2.2.2
  libstatistics_collector:
    type: git
    url: https://github.com/ros-tooling/libstatistics_collector.git
    version: 1.1.0
  libyaml_vendor:
    type: git
    url: https://github.com/ros2/libyaml_vendor.git
    version: 1.2.0
  message_filters:
    type: git
    url: https://github.com/ros2/message_filters.git
    version: 4.2.0
  navigation_msgs:
    type: git
    url: https://github.com/ros-planning/navigation_msgs.git
    version: 2.1.0
  orocos_kinematics_dynamics:
    type: git
    url: https://github.com/ros2/orocos_kinematics_dynamics.git
    version: 3.3.3
  perception_pcl:
    type: git
    url: https://github.com/ros-perception/perception_pcl.git
    version: 2.4.0
  pluginlib:
    type: git
    url: https://github.com/ros/pluginlib.git
    version: 5.0.0
  pybind11_vendor:
    type: git
    url: https://github.com/ros2/pybind11_vendor.git
    version: 2.2.6
  qt_gui_core:
    type: git
    url: https://github.com/ros-visualization/qt_gui_core.git
    version: 2.1.0
  rcl:
    type: git
    url: https://github.com/ros2/rcl.git
    version: 4.0.0
  rcl_interfaces:
    type: git
    url: https://github.com/ros2/rcl_interfaces.git
    version: 1.1.0
  rcl_logging:
    type: git
    url: https://github.com/ros2/rcl_logging.git
    version: 2.2.0
  rclcpp:
    type: git
    url: https://github.com/ros2/rclcpp.git
    version: 13.1.0
  rcpputils:
    type: git
    url: https://github.com/ros2/rcpputils.git
    version: 2.3.0
  rcutils:
    type: git
    url: https://github.com/ros2/rcutils.git
    version: 5.0.0
  realtime_support:
    type: git
    url: https://github.com/ros2/realtime_support.git
    version: 0.11.0
  resource_retriever:
    type: git
    url: https://github.com/ros/resource_retriever.git
    version: 2.5.0
  rmw:
    type: git
    url: https://github.com/ros2/rmw.git
    version: 5.1.0
  rmw_dds_common:
    type: git
    url: https://github.com/ros2/rmw_dds_common.git
    version: 1.4.0
  rmw_fastrtps:
    type: git
    url: https://github.com/ros2/rmw_fastrtps.git
    version: 6.1.0
  robot_state_publisher:
    type: git
    url: https://github.com/ros/robot_state_publisher.git
    version: 2.7.0
  ros2_tracing:
    type: git
    url: https://gitlab.com/ros-tracing/ros2_tracing.git
    version: 3.1.0
  rosbag2:
    type: git
    url: https://github.com/ros2/rosbag2.git
    version: 0.11.0
  rosidl:
    type: git
    url: https://github.com/ros2/rosidl.git
    version: 3.0.0
  rosidl_typesupport:
    type: git
    url: https://github.com/ros2/rosidl_typesupport.git
    version: 1.4.1
  rosidl_typesupport_fastrtps:
    type: git
    url: https://github.com/ros2/rosidl_typesupport_fastrtps.git
    version: 2.0.3
  rqt:
    type: git
    url: https://github.com/ros-visualization/rqt.git
    version: 1.1.2
  rqt_image_view:
    type: git
    url: https://github.com/ros-visualization/rqt_image_view.git
    version: 1.1.1
  rviz:
    type: git
    url: https://github.com/ros2/rviz.git
    version: 9.0.0
  teleop_twist_joy:
    type: git
    url: https://github.com/ros2/teleop_twist_joy.git
    version: 2.4.3
  tlsf:
    type: git
    url: https://github.com/ros2/tlsf.git
    version: 0.5.2
  turtlesim:
    type: git
    url: https://github.com/ros/ros_tutorials.git
    version: 1.4.0
  unique_identifier_msgs:
    type: git
    url: https://github.com/ros2/unique_identifier_msgs.git
    version: 2.2.1
  urdf:
    type: git
    url: https://github.com/ros2/urdf.git
    version: 2.5.2
  urdfdom:
    type: git
    url: https://github.com/ros/urdfdom.git
    version: 2.3.5
  urdfdom_headers:
    type: git
    url: https://github.com/ros/urdfdom_headers.git
    version: 1.0.5
  vision_opencv:
    type: git
    url: https://github.com/ros-perception/vision_opencv.git
    version: 2.2.1

You have closed it but don't you give depreciation warnings for the feature fixed here? I wouldn't make significant changes for features to be depreciated. That looks pretty weak to me if so. (Actually I didn't encounter the problem mentioned here but read in the discussion. And I do not want to rely on ROS tooling as much as possible. Just wanted to switch from galactic to humble.)

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/deprecate-ament-packages/26988/20