Project

General

Profile

Actions

Bug #331

closed

update gazebo from 9 to 11 on hydra64-ubuntu2004

Added by Guilhem Saurel over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-

Description

Hi,

Ubuntu 20.04 provides gazebo 9 and 11.

ROS noetic binary packages depend on gazebo 11 (or at least ros-noetic-desktop-full ros-noetic-gazebo-dev ros-noetic-gazebo-plugins ros-noetic-gazebo-ros ros-noetic-gazebo-ros-control ros-noetic-gazebo-ros-pkgs ros-noetic-simulators ros-noetic-urdf-sim-tutorial)

robotpkg binary packages depend on gazebo 9 (or at least robotpkg-pal-gazebo-plugins robotpkg-pal-gazebo-worlds robotpkg-pal-hardware-gazebo robotpkg-prf-roboticsgroup-gazebo-plugins robotpkg-py38-prf-gazebo-ros-pkgs robotpkg-py38-talos-dev robotpkg-talos-simulation)

And… gazebo 9 and 11 are conflicting, which is a bit inconvenint, as we would like to have both ros-noetic-desktop-full & robotpkg-py38-talos-dev.
I think replacing gazebo9 by gazebo11 on hydra64-ubuntu2004 would workaround this issue.

Could we try that ?

Actions #1

Updated by Anthony Mallet over 2 years ago

On Tuesday 5 Oct 2021, at 15:53, Guilhem Saurel wrote:

Ubuntu 20.04 provides gazebo 9 and 11.

Maybe initially there was only gazebo 9, that's why this is what is
installed. Otherwise I prefer to have the most recent for bulk builds.

I think replacing gazebo9 by gazebo11 on hydra64-ubuntu2004 would
workaround this issue.

Yes, done.

There are obscure issues on Ubuntu-21.04 with gazebo-11, but let's see
what happens. On my workstation I'm using gazebo-11 and ubuntu-20.04
just fine.

I also triggered a new bulk build.
Normally, all packages depending on gazebo should increase PKGREVISION
to catch the dependency update properly. We will probably not bother
with that, but packages should be rebuilt (because there is a
minimalistic dependency tracking through SYSTEM_SEARCH). So apt update
may get a bit confused. Or maybe not :)

Actions #2

Updated by Anthony Mallet over 2 years ago

I was wrong: the SYSTEM_SEARCH files are not used to check if a binary
package needs rebuilding. SYSTEM_SEARCH is currently used only to
generate the system dependencies for the .deb packages.

I could easily fix that, but at the moment, the result is that
packages that depend on gazebo have not necessarily been rebuilt yet
(only as a side effect of the recent hpp update, for that matters).

Do you think it is a good idea to check for the timestamp of files in
SYSTEM_SEARCH and trigger a rebuild if anything is newer than the
binary package? (a consequence would be that more package would
potentially change without a change in the version/revision number).

Actions #3

Updated by Guilhem Saurel over 2 years ago

I don't think this would be worth it. A PKGREVISION bump will solve all issues that could arise from such situations. And I expect such situations to occur at very low frequency.

Actions #4

Updated by Anthony Mallet over 2 years ago

OK, that's right.

In practice, this happens each time system packages are updated
upstream. It can be worth checking that the builds are still OK with
the update. However, binary packages would require the most recent
system dependencies, which is not good.

Actions #5

Updated by Guilhem Saurel over 2 years ago

  • Status changed from New to Closed

Everything looks good to me now, thanks :)

Actions

Also available in: Atom PDF