ros_buildfarm cannot support rosdep virtual packages

ros-infrastructure / ros_buildfarm

ROS buildfarm based on Docker

Apache License 2.0

82 stars 96 forks source link

ros_buildfarm cannot support rosdep virtual packages #557

Open tfoote opened 6 years ago

tfoote commented 6 years ago

Our driving example was: ros/rosdistro#15308

rosdep support was added in https://github.com/ros-infrastructure/rosdep/pull/585 and https://github.com/ros-infrastructure/rosdep/pull/521

However after that was verified we found that the ros_buildfarm doesn't use the same rosdep code paths and was causing regressions on the buildfarm. In particular the devel jobs.

And we reverted the libcurl change: https://github.com/ros/rosdistro/pull/18223

Another instance was just found: ros/rosdistro#18272 where a previously used package has been changed to be a virtual package.

The query logic needs to be extended to support virtual packages that are provided by other packages in the same way that rosdep was extended.

dirk-thomas commented 5 years ago

@tfoote What is the status of this?

tfoote commented 5 years ago

There has been no progress, I haven't had time for buildfarm work.

dirk-thomas commented 5 years ago

I was asking since the ticket is currently assigned to you. Maybe unassigned it if you are not planning to work on it soon?

cottsay commented 2 years ago

This won't be trivial to implement without some refactoring.

It was possible in rosdep because it checks to see if a virtual package provider is installed before grabbing the first candidate and specifically attempting installation.

The code in ros_buildfarm resolves the list of package names to be installed to their versions via apt prior to building the container image, so there isn't a system state to query for already installed packages. Additionally, another dependency in the list (or a recursive dependency thereof) may already satisfy the virtual package. Both of these situations could result in attempting installation of more than one provider, which may be mutually exclusive (as is the case for libcurl-foo-dev).