ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

"upstream packages" becoming increasingly a problem

It could be unlucky sampling or a temporary surge, but we’ve had about 4 to 5 Q&As on ROS Answers in the past week alone where in the end it turned out the problems reported by the OP were caused by UpstreamPackages. Over the past few months (years?) there’s also always been a few each month.

While there is great value in those upstreamed packages (ever try using ROS on a armel or mips target and don’t want to wait 5 hours before everything is compiled?) they seem to be causing an increasing nr of problems for new users, leading to increased nrs of posts to ROS Answers.

I’m not at all advocating for getting them removed, but perhaps we need to inform or warn (new) users better or in a different way such that we can avoid them installing ros-desktop-full instead of ros-$distro-desktop-full (even more confusing are the Python packages: python-roslaunch vs ros-$distro-roslaunch).

An admonition is easily added to the installation tutorials, but perhaps there is someone here who might have a more creative idea.

After all: who pays attention to admonitions? We just copy-paste installation instructions into a terminal, and users who end up installing any of the upstream packages most likely haven’t read/seen/used any of the tutorials in the first place (as they don’t mention them), so they would not see those admonitions.

1 Like

Thanks for bringing this up and answering on ROS Answers as well.

When starting this initiative I had the idea of merging the packages with those provided by OSRF. This could be by providing an apt repository with the OSRF packages compiled against the base set in Debian/Ubuntu and providing it as a PPA, for example. I have a half finished script to automate this from back them, if someone wants to continue on it.

An other option would be to make the OSRF package aware of the versions in Debian/Ubuntu. This could be by declaring relations: https://www.debian.org/doc/debian-policy/ch-relationships.html and would allow to provide OSRF package as upgrades. Note that this can’t be done in the Debian/Ubuntu packages because those are created and released long before those by OSRF. AFAIK this is already the case for python-* packages.

I’m unsure if there is a fitting tool to provide information about the OSRF repo. While we can’t change apt, obviously, maybe it would make sense to add a note to rosdep?

1 Like

If I understand the documentation correctly, that would require adding Replaces to all ROS packages that potentially conflict with the upstream packages?

Or are you thinking of using any of the other keywords?

Normally a versioned Replaces and Breaks is used, see: https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages. Should be easy to test.

But wouldn’t in this case all upstream packages need to be replaced? What would the version be in this case?

As I wrote: I like the fact they’re available, but for people installing (or attempting to install) ros-$distro-*, they should just be removed whenever the packages.ros.org ones are being installed.

An error message, a log entry, or a clear indication of what version is being used when roscore starts could help (You are using an installation of ROS packaged by Debian - in case you run into any problem, please send a bug to <debian email> etc.).
The main drawback of adding a break&replace is that any Debian package depending on ROS upstream packages become impossible to install the moment you want you want to install OSRF packages. If your 3d model editor depends on URDF, installing ros-*-desktop will uninstall your 3d model editor (I don’t what could be the impact of this, probably @jspricke have a better idea than me).

That would be great, but there are enough cases where users start installing packages like python-rosdep2 and python-roslib, only to realise that they need other packages. At this point they try to follow the regular installation tutorial, try to install ros-$distro-desktop-full and it fails.

So they can’t run roscore (or any other tool), as they only have a bunch of packages that don’t function.

Or at least, this has been posted by a nr of people on ROS Answers.

apt doesn’t do a very good job of reporting exactly what causes a failed installation, often it just states “X needs Y, but Y isn’t going to be installed”. aptitude is then sometimes used, but isn’t able to always figure things out either.

That’s exactly why I would propose to add the package relationships (why printing an error if you could just make it work :wink: ).

I’m not sure this is even needed. All ROS packages use the /opt/ros space, whereas the Debian packages are in /usr. Can you point to specific problems? It’s probably easier to propose something then.

Hi Thomas, good to see you around :). Yeah that’s a valid point and we have problems like this already (for example with the different OpenCV version we had in kinetic, or with a new Gazebo version). This is where I think a PPA, or multiple, could work out. We could have one that only tracks packages not in Debian/Ubuntu or one that imports new versions from Debian unstable or one that doesn’t break ABIs… I think there are a lot of options and it could work as a fallback to the OSRF build farm as well. But this depends on what people want and who takes action. Obviously an other option would be to package more software into Debian but I’m currently busy with the Python 3 transition and lately I didn’t need much more then rviz and rosbag.

While the is the case for ROS packages (having a package.xml file and being released with bloom).

But the ROS distro agnostic pure Python packages like catkin_pkg are being installed under /usr and therefore conflict with the upstream Debian package equivalent. Therefore they declare a conflict to prevent mixing them: e.g. https://github.com/ros-infrastructure/catkin_pkg/blob/8c90ff8b7d5458acdba9faaedf10c86656708233/stdeb.cfg#L11-L12

Note the Debian packages for catkin_pkg - upstreamed into Debian as well as from the ROS repos - have the name package name. Therefore for the conflict we picked the Debian upstream of catkin a while ago.