Declare conflict between Gazebo packages in packages.osrfoundation.org and packages.ros.org (vendor packages)

[azeey]

The Gazebo vendor packages in packages.ros.org may not be compatible with the packages in packages.osrfoundation.org:

1. They may not have the same features. e.g In Ionic and earlier, the vendor packages did not support Python
2. They may not be compiles with the same dependencies. e.g. In Jetty, the version of zenoh in packages.osrf may be different from packages.ros
3. They may not have the same compilation flags.
4. Due to the manual step involved in making the vendor package releases and the extra time it takes for the release to go through rosdistro, the repos might have different versions of a given library. Related: ABI problems when mixing packages.o.o debian packages and ROS vendor packages gz_vendor#15

For all these reasons, it might be wise to declare conflicts to these packages so that users don't accidentally try to install and use Gazebo from both sources and run into hard-to-debug issues.

Thanks @iche033 for bringing this up.

[j-rivero]

I agree that it is dangerous to mix different packaging schemas in the same system and that created us problems with that Python ABI inestability. In the other hand, we have been using that combination (ROS vendor + system packages) to generate a system with ROS Humble vendor packages + python support (missing because of gazebo-tooling/gz_vendor#2).

Ideally we can resolve gazebo-tooling/gz_vendor#2 for Gazebo distributions prior to Jetty.

To declare the conflict, we can do it in three ways:

• In system packages declare ROS vendor conflicts:
  • 👍 Trivial to implement in -release repos.
  • 👍 Gazebo core team controls when and how they change or are updated.
  • ⬇️ Packages need updates when a new ROS version is out (i.e gz-cmake4 conflicts with ros-kilted-gz-cmake-vendor but could also need a conflict on ROS Lyrical if it uses gz-cmake4).
• In ROS vendor packages declare the system conflict:
  • ⬇️ if using package.xml then rosdep needs to know about Gazebo keys (rosdistro support for all gazebo libraries).
  • We can inject bloom patches in the ROS gbp release repositories. Patches can be hosted in per-ROS-release branches so we obtain the 1 to 1 relationship for the conflict (i.e: gz-cmake-vendor in Kilted conflicts always with gz-cmake4 since it will have the 4.x series forever).
    • 👍 That 1 to 1 immutable relationship is solid and do not need updates.
    • ⬇️ This is valid for all the releases with the exception of Rolling that needs to update patches when the whole Gazebo version is updated (from Jetty to Gazebo K)
• Do in both system and vendor: declaring a Breaks: in debian can probably make the apt tool to resolve the conflicts in both ways without having to supply.

The other point is: in which libraries do we want to include the conflict cause? I assume that for a minimum maintenance effort we can target just one, gz-cmake (even if this package is unlikely to have problems in parallel installations).

[j-rivero]

In ROS vendor packages declare the system conflict:

After discussed this in the Gazebo PMC we believe that the right option is to do it in the ROS vendor package. To do so, we only need to add a commit to the -release repository in gbp2 and get a new release out.

I would like to resolve first the gazebo-tooling/gz_vendor#2 for getting the Python bindings out since it is one of the use cases of mixing both packages.o.o + ROS Gazebo vendor packages.