libopen3d-dev not available on Ubuntu 24.04 (Noble)

[SteveMacenski]

Checklist

• I have searched for similar issues.
• For Python issues, I have tested with the latest development wheel.
• I have checked the release documentation and the latest documentation (for main branch).

Steps to reproduce the issue

apt install libopen3d-dev

Error message

N/A

Open3D, Python and System information

- Operating system: Ubuntu 24.04

Additional information

I'm a maintainer on https://github.com/ros-perception/perception_open3d the Open3D conversion tools for the ROS ecosystem and we've recently migrated to 24.04 but the Open3D binaries are missing so it cannot be compiled, released, or apt installable for ROS users.

Do you intend to release Open3D in binaries to 24.04 (Noble) or should I plan to remove binaries from ROS for the conversion kit?

[ssheorey]

@roehling Can you please take a look at this one?

[roehling]

Unfortunately, I was not involved in the decision to drop Open3D from Ubuntu Noble. I suspect they have problems with PyTorch, and I recently added PyTorch support to the Debian release, but I cannot tell for sure. I'm trying to find out and see if they are willing to re-add the package, but it is already quite late in their release cycle, so no promises.

[tirolerstefan]

Hi @roehling, if it's not possible to get it into 24.04, would you think about creating a PPA hosting the package for Noble? Thanks for your answer!

[roehling]

I already have a PPA for Ubuntu 20.04, so yes, I am planning to host Open3D binaries for 24.04 there, as a fallback solution.

[SteveMacenski]

That would cause us problems in ROS-land unfortunately for releasing any binaries that rely on Open3D since the ROS build farm cannot have PPAs added :frown: We'd have to remove those from ROS and any users would need to compile from source (and anything that relies on it from source, and so on) or setup a vendorization package to build from source in the ROS build farm and release via a open3d_vendor package that is build in the ROS build farm on the ROS index

[tirolerstefan]

Hi Timo @roehling, we are also thinking about disabling open3d in our code for now - or do you already have an idea when the packages in your ppa might be available? Thanks for all!

[SteveMacenski]

We were forced to remove the CI jobs from the ROS community since the binaries aren't available. Its easy enough to kick them back on once they're available as long as its not behind a non-default PPA (else will involve a bit of work requiring us to compile from source on ROS infrastructure)

[ssheorey]

Hi @SteveMacenski @tirolerstefan are any other sources of binary repos acceptable? We can host them on github releases, for example, for direct download.

Also, if you have specific build needs / configs for ROS, we can include them in the Open3D repo to make building binaries easy for ROS users. Please submit a PR.

[SteveMacenski]

Also, if you have specific build needs / configs for ROS, we can include them in the Open3D repo to make building binaries easy for ROS users. Please submit a PR.

I'll preface this that I'm an intermediate, not expert, at the ROS release infrastructure. I know alot, but I also ack that I don't know everything. So there may be other options available, but this is the best of my understanding.

ROS package management allows us to specify keys for completely external projects that can be installed using rosdep. The index is stored here so that we can call out external non-ROS dependencies and have the package.xml know for a given key what binaries it needs to grab for the Tier-1 supported operating systems. This only works with default repositories though, I don't believe there is a way to allow for PPAs in this unless something has changed in the last 2-3 years from the last time I ran into this.

So if binaries are not available by default, then our next option is to vendorize the packages. That essentially means running a ROS build farm job to compile the code and release it within the ROS ecosystem as if it were a ROS package itself. There are tools like ament_vendor to make this easy (example). That way, now we have the open3d_vendor key that we can use with our package.xml files to install that version of it instead. But now ROS build farm would be owning the overhead of compiling Open3D and its another thing that would need to be periodically released.

With all that mentioned: for any single user for any single application, they can ExternalProject Open3D or pull in some binaries from your release page without a problem. The issue here is that the ROS Build Farm does everything in a high degree of isolation so it only has the dependencies installed that the package.xml calls out. So, anyone that would like to release a ROS project for binary builds that depends on Open3D will be unable to - such as perception_open3d and others. For example, I couldn't use Open3D in Nav2 because I have to be able to release binaries to users. If they/we/I external project Open3D, then its better for Open3D to provide its own ROS vendor so that the build farm isn't rebuilding open3D for dozens of packages independently (just once)

That is, I suppose, unless those packges grabbed your binaries from the release page, but that seems like a big security risk for ROS package distribution. This is where I'm a little fuzzy about the policies here. I don't think they'd allow that to get into the build farm doing something like that, but I also don't know that they wouldn't either. Its not a question I've ever seriously posed, I usually went the vendor direction as preferable.

So... missing the 24.04 cut off or conflict actually does create a bit of an issue if its a goal for Open3D to be easily compatible with ROS 😢

[tirolerstefan]

For us, any PPA or direct download would be ok.

[ssheorey]

@tirolerstefan please use the binaries from github release (check the assets section in the release page for direct links for your chosen binary).

https://github.com/isl-org/Open3D/releases/tag/v0.18.0

Note that these are "all included" binaries, so they do not depend on other OS / system packages (except very basic packages). This is unlike the Debian binaries that are built to maximize package reuse.

[tirolerstefan]

Sorry, maybe I was not precise enough. We are mirroring debian packages into our own repository, so we would need debian packages, but for us it doesn't matter whether they come from Noble's or your PPA.
Timo said it would be possible to host those noble compatible packages in his / your custom PPA as a fallback.