robotpkg

I guess this could be managed with a "ros alternative", simlilar to
python packages (optionnaly including the alternative in the package
name, depending on the goals).

Currently, there is already a ros alternative to select among ros1
versions. My plan was to deprecate this, as there is no point to
select a ros1 version anymore. I also did not add a ros2 alternative
on purpose, as the ros1 alternative has never been useful: people use
whatever ros version is present on their system and don't care.

So, once the ros1 alternative is gone, it should be possible to
transform it into a "ros1 vs. ros2" selection.

The alternative-dependent dependencies could be managed via the
PKG_ALTERNATIVE_SET.ros{1,2} hooks (hoping this works, sometimes there
are hairy issues with this, but my intuition is that it should work).

To answer some of your other questions:

• I don't know any other packages in robotpkg that knows about ros1
  and 2 at the same time (genom components are expected to use
  different templates, so this is (will be) already managed via the
  existing genom building options)

• Building or not binary packages for ros1 alternatives on recent
  distributions is a matter of choice, we can do it or not (possible
  only if the alternative name is included in the packages name, as
  with python). But it should definitely remain possible to build a
  ros1 package on recent distribution if the user configures its
  robotpkg to do so (this does not require the alternative name in the
  package name). I guess we don't care that both can be installed
  simultaneously, also.

What do you think about this?

Thanks, I think this is a good solution.

We won't have different ROS 2 version, but we already saw with ROS 1 that we don't need that.

Building for ros1 alternative is still a good idea, as long as it don't require too much additional work to maintain older packages. So I guess we can just decide to build them until we decide to stop building them. And this can be decided package by package if necessary.

About the simultaneous installation, I'm not sure. ROS binary packages are separated in /opt/ros/<version>, but this won't be the case for us, so they will be conflicts between installed files. At least, apt will probably not like it.

Do you have an idea of how many packages would be concerned?

I started to work on the alternative, which works, but the PLIST have
nothing in common (at least for motion/dynamic-graph-bridge-msgs).
So this makes complex packages:
- handle totally different dependencies (ok)
- prefix the name with ros/ros2 so that dependency works (ok-ish).
- have two different PLIST (.ros, .ros2) (ok)
- Deal in some way with SYSTEM_SEARCH (not found how exactly yet)

But all in all, if it is only a couple of packages that will need
this, maybe having completely separate packages will be easier to deal
with.

Ok, I can maintain motion/ros-dynamic-graph-bridge-msgs and motion/ros2-dynamic-graph-bridge-msgs, this would probably be easier and faster for me.

On Thursday 10 Aug 2023, at 18:31, Guilhem Saurel wrote:

Ok, I can maintain motion/ros-dynamic-graph-bridge-msgs and
motion/ros2-dynamic-graph-bridge-msgs, this would probably be easier
and faster for me.

If that's the only one, yes, definitely.

One can keep motion/dynamic-graph-bridge-msgs as is, and just create
the new one as motion/ros2-dynamic-graph-bridge-msgs.
I already started with this one, so I can push the ros2 version soon
if you like.

this won't be the only one, as this is only the first of the dependency chain, but this chain is not that huge.
Yes, if you have something that work for you, it will make a nice example for the others, thanks !

I finally pushed a new package motion/dynamic-graph-bridge-msgs-ros2
that will be compiled for ros2.

On Ubuntu-22.04, the binary package will use ros/rolling, as suggested by
Olivier Stasse. On other distributions, it will use robotpkg version
which contains more or less ros-rolling versions, with a bit of lag due
to lazyness :) (but each ros2- package can be upgraded on an
individual basis when needed).

The naming scheme is as follow:
ros2- indicates an 'official' package part of ros distribution.
*-ros2 indicates a regular package, not part of ros distribution, but
using ros2-* packages :)

Tell me if you have any issue!