Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

libgazebo9 is not packaged for stretch #19843

Merged
merged 1 commit into from
Sep 30, 2019
Merged

libgazebo9 is not packaged for stretch #19843

merged 1 commit into from
Sep 30, 2019

Conversation

tfoote
Copy link
Member

@tfoote tfoote commented Jan 2, 2019

Follow up to #17750

@clalancette this will effect melodic packages depending on gazebo they have to use the generic gazebo tag not the version specific one.
@j-rivero FYI

Related to this I'm wondering if we really want the gazebo9 tags in the main rosdep database at all. Like any other system dependency we expect to use the system version on all targeted platforms and as such we should just have one key that everyone uses to avoid this issue of packaging things that are uninstallable due to conflicting apt rules.

From: https://packages.debian.org/search?searchon=names&keywords=libgazebo

Package libgazebo7
stretch (stable) (libs): Open Source Robotics Simulator - shared library 
7.3.1+dfsg-3: amd64 arm64 armhf i386 mips mips64el mipsel
sid (unstable) (libs): Open Source Robotics Simulator - shared library 
7.8.1+dfsg-4+b1 [debports]: m68k sh4 
7.5.0+dfsg-1 [debports]: hppa
Package libgazebo7-dbgsym
sid (unstable) (debug): debug symbols for libgazebo7 
7.8.1+dfsg-4+b1 [debports]: m68k sh4 
7.5.0+dfsg-1 [debports]: hppa
Package libgazebo7-dev
stretch (stable) (libdevel): Open Source Robotics Simulator - Development Files 
7.3.1+dfsg-3: amd64 arm64 armhf i386 mips mips64el mipsel
sid (unstable) (libdevel): Open Source Robotics Simulator - Development Files 
7.8.1+dfsg-4+b1 [debports]: m68k sh4 
7.5.0+dfsg-1 [debports]: hppa
Package libgazebo9
buster (testing) (libs): Open Source Robotics Simulator - shared library 
9.4.1+dfsg-1+b1: amd64 i386
sid (unstable) (libs): Open Source Robotics Simulator - shared library 
9.4.1+dfsg-1+b1: amd64 i386
Package libgazebo9-dev
buster (testing) (libdevel): Open Source Robotics Simulator - Development Files 
9.4.1+dfsg-1+b1: amd64 i386
sid (unstable) (libdevel): Open Source Robotics Simulator - Development Files 
9.4.1+dfsg-1+b1: amd64 i386

@tfoote tfoote mentioned this pull request Jan 2, 2019
Merged
@clalancette
Copy link
Contributor

Hm, I thought we had solved this back when we released Melodic. @j-rivero ended up packaging gazebo9 for Debian Stretch, and it is hosted at http://packages.osrfoundation.org/gazebo/debian-stable/. Is that not enough for it to resolve in the rosdep database?

@tfoote
Copy link
Member Author

tfoote commented Jan 2, 2019

If it's not in the ROS repo or upstream it shouldn't be in the rosdep database. I believe there's an alternative rosdep source for packages.osrfoundation.org that you can optionally add if you add packages.osrfoundation.org to your apt sources.

@tfoote
Copy link
Member Author

tfoote commented Jan 3, 2019

THis is a bit of an issue as looking at REP 3 it looks like we've explicitly chosen to backport gazebo9 for stretch in melodic, but gazebo7 was still specified for stretch in Lunar which included stretch.

http://www.ros.org/reps/rep-0003.html#melodic-morenia-may-2018-may-2023

@mikaelarguedas
Copy link
Member

@tfoote yeah that's an issue we discussed before making the decision of using gazebo9 across the board for Melodic.

TL;DR

  • users should depend on gazebo_dev or gazebo_ros instead of the generic gazebo key. This allows to not pin down versions in package.xml while targetting the right gazebo version based on the ROS distro.
  • Once Lunar is EOL we could consider changing the gazebo rosdep key to point to gazebo9 instead of gazebo7

My recollection in more details:

I believe the issue user faced is that the rosdep key for gazebo points to gazebo 7 for Stretch.
This has been done purposefully to not change the version under Lunar user's feet.
This is similar to what we did for Jade on trusty:

  • Jade targeted gazebo 5
  • Indigo targeted gazebo 2
  • Keys for gazebo 5 were added and used for gazebo_ros and friends. the generic gazebo key was not updated and still points to gazebo2.

moriarty added a commit to moriarty/fetch_gazebo that referenced this pull request Apr 2, 2019
@moriarty
[fetch_gazebo] build depend on gazebo_dev
85b76da 
We have some builds failing on Debian Stretch. I came across this issue:
ros/rosdistro#19843
moriarty added a commit to moriarty/fetch_gazebo that referenced this pull request Apr 2, 2019
@moriarty
[FetchIt!] remove all build depends
351d43f 
This package only contains two bash scripts, urdfs, some models and
launchfiles.

This package is currently failing on the build farm for all debian
Stretch binary builds (amd64 and arm64)

When it tries to install the dependencies there are many
Gazebo7/Gazebo9, and sdformat4/sdformat6 conflicts.

http://build.ros.org/job/Mbin_ds_dS64__fetchit_challenge__debian_stretch_amd64__binary/

Possibly related to ros/rosdistro#19843
@moriarty moriarty mentioned this pull request Apr 2, 2019
Merged
moriarty added a commit to ZebraDevs/fetch_gazebo that referenced this pull request Apr 4, 2019
@moriarty
Cleanup dependencies (#68)
08d39c6 
* [fetch_gazebo] build depend on gazebo_dev
    We have some builds failing on Debian Stretch. I came across this issue:
    ros/rosdistro#19843
* [FetchIt!] remove all build depends
    This package only contains two bash scripts, urdfs, some models and
 launchfiles.
    This package is currently failing on the build farm for all debian
Stretch binary builds (amd64 and arm64)
    When it tries to install the dependencies there are many
Gazebo7/Gazebo9, and sdformat4/sdformat6 conflicts.
@clalancette clalancette mentioned this pull request Sep 25, 2019
Closed
@dpkoch
Copy link
Contributor

dpkoch commented Sep 25, 2019 •
edited
Loading

Should this (changing the debian stretch gazebo key to point to gazebo9) be revisited now that Lunar is EOL? Based on the second bullet in the previous comment.

Context for why I'm bringing this up again is in #22360. It looks like using the gazebo_dev key instead of the gazebo key also fixes my problem, but is changing the gazebo key to point to gazebo9 for stretch the correct long-term solution?

@tfoote
Update gazebo9 targets for newer ubuntu and debian targets
4052f7a 
This also switches stretch from gazebo7 to gazebo9 now that Lunar is EOL.
On Melodic gazebo9 is the standard for stretch. This switches to prefer the still supported target over the legacy one for lunar which is EOL.

Stretch itself is now oldstable as well.

Signed-off-by: Tully Foote <tfoote@osrfoundation.org>
@tfoote tfoote requested a review from a team as a code owner September 26, 2019 01:44
@tfoote
Copy link
Member Author

tfoote commented Sep 26, 2019

Thanks for the ping back. I think it's time to switch the key forward. I've refactored this PR to do that.

@tfoote tfoote merged commit d2caa5e into master Sep 30, 2019
@tfoote tfoote deleted the tfoote-patch-1 branch September 30, 2019 22:04
This was referenced Oct 19, 2019
Open
Merged
@tfoote tfoote mentioned this pull request Mar 10, 2020
Closed
@tfoote tfoote mentioned this pull request Feb 2, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@clalancette clalancette clalancette approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@tfoote @clalancette @mikaelarguedas @dpkoch