add libcamera to humble and rolling

[christianrauch]

Please add the following dependency to the rosdep database. This is only the source for now in order to prepare for a new release repo (https://docs.ros.org/en/foxy/How-To-Guides/Releasing/Release-Team-Repository.html#create-a-new-release-repository).

Package name:

libcamera

Package Upstream Source:

https://git.libcamera.org/libcamera/libcamera.git

Purpose of using this:

libcamera is a library for using different kind of cameras.

Please Add This Package to be indexed in the rosdistro.

humble, rolling

[sloretz]

It looks like this PR is adding a source entry for libcamera, but that doesn't appear to be a ROS package. Did you intend to create a rosdep key instead? (maybe libcamera-dev?)

Here's an example PR adding a rosdep key: #34920

There's some more info about adding rosdep keys here: https://github.com/ros/rosdistro/blob/master/CONTRIBUTING.md#rosdep-rules-contributions

[tfoote]

This is in ubuntu too. As such it should be targeted as a rosdep and not as a ROS package.

https://packages.ubuntu.com/source/impish/libcamera

[tfoote]

I'm going to close this. Please reopen it as a PR for a rosdep rule.

[christianrauch]

This is indeed intended to be added as a colcon package to the ROS repo. The libcamera version distributed with Ubuntu is outdated. The relation is the same as for https://packages.ubuntu.com/jammy/apriltag and ros-humble-apriltag. Both exist in parallel for a reason.

Is there a reason why a more recent version of libcamera cannot be distributed in the ROS repo? Can you please open this PR again and consider it for merging?

[christianrauch]

@sloretz @tfoote Can you please reopen this PR or justify why libcamera cannot become a ROS package?

[nuclearsandwich]

Our policy is not to add packages to ROS which can conflict with packages available on the underlying platform, preferring instead to use the platform version.

There will always be updates to packages that are compelling and "worth updating" for particular applications. But the objective of the official ROS repositories is to manage the entire ROS distribution together, and ensure as much mutual compatibility as possible. To achieve that we rely heavily on the work done by the much larger communities in Debian, Ubuntu, and our other target platforms to package and integrate software. In order to successfully build on top of those systems we also inherit some of their policies. In this case, avoiding packaging multiple versions of the same package.

---

Since you raise apriltag as a counter-example, I'll start by saying that each of these cases has enough nuance to be considered individually and where possible I'll try to rely more on rationale than precedence, which is to say that rejecting or accepting libcamera on its own would not be a sufficient argument to accept or reject future packages in this same scenario. However the explained rationale for the decision is much more likely to be applicable to other packages in similar situations.

The primary difference between apriltag and libcamera is that apriltag is already available in ROS and so there will be some effort/cost required in order to switch that to a system dependency. I think that the correct course of action is actually to drop the standalone apriltag package from Rolling, preferring instead the version available upstream, then when the next ROS distributions are branched from Rolling, they will use the system dependency naturally and the system version of apriltag is the one to keep up-to-date within the limits of stable distribution release cycles.

There is nuance to this as Rolling's other platforms: Debian Bullseye and RHEL 8 may not be as well poised to supply a usable version of apriltag from their expected sources. However that gap could be bridged by transitioning the apriltag package in ROS to a vendor-style package which will only build and install apriltag if it cannot be found on the system.

---

One situation where I could see a strong case for including a version of libcamera in ROS in spite of its availability on target platforms is if the version available from the system is unusably broken thus making it unlikely that any ROS package would ever interact with or cross-link with the system library. The requirements for demonstrating this would be exceedingly strict and on Ubuntu at least, would probably overlap with the Stable Release Update procedures which should be tried first before trying to push an updated version to the ROS repositories.

---

I can't guarantee that you'll like this justification but I do hope it's at least understood and acceptable. I'll also point out that what I've written constitutes my own understanding and that it may not match precisely with the reasons given by other members of the ROS team.

[tfoote]

Looking at the apriltag repo we should start the transition to using the rosdep key instead of packaging it ourselves. Thanks for flagging that it's not available. I've ticketed to change that and not have us shadow the upstream version of that: #35273

[christianrauch]

Our policy is not to add packages to ROS which can conflict with packages available on the underlying platform, preferring instead to use the platform version.

I was not aware that such a policy exists. There always have been alternative versions of system packages in the ROS repos, e.g. for OpenCV, so I did not expect this to be suddenly a problem. Especially since the ROS workspace is a separate environment that has to be sourced first.

There is nuance to this as Rolling's other platforms: Debian Bullseye and RHEL 8 may not be as well poised to supply a usable version of apriltag from their expected sources.

All those target platforms may have different versions of a library, or do not ship the library in question at all. How can we cover all those cases and make sure that a ROS package depends on the correct version?

One situation where I could see a strong case for including a version of libcamera in ROS in spite of its availability on target platforms is if the version available from the system is unusably broken thus making it unlikely that any ROS package would ever interact with or cross-link with the system library.

I can only speak for libcamera. This is a relatively new library with an unstable API. The version in Ubuntu is already outdated. Having to rely on an outdated library with limited support for cameras for the whole duration of the Ubuntu 22.04 lifetime (5 years) is not promising. Most packages do not even receive that long support. For most packages, support ends after 2~3 years.

The requirements for demonstrating this would be exceedingly strict and on Ubuntu at least, would probably overlap with the Stable Release Update procedures which should be tried first before trying to push an updated version to the ROS repositories.

What would the expected outcome of this? Do you expect ROS users to track down the package maintainers for every supported Linux distribution and motivate them to update the package and push a new version to a stable release?
Ubuntu has a policy to not update packages unless those are security and bug fixes. Even if they are willing to do this in general, Ubuntu does not have a track record of resolving critical problems quickly. Does anyone remember Ubuntu's buggy Eigen3 version that stayed buggy for more than a year?

I can't guarantee that you'll like this justification but I do hope it's at least understood and acceptable.

I can understand that you do not want to have the very same version in the system and the ROS repos. But for most situations, I don't see the advantage of relying on outdated packages for 5 years. ROS has published packages in the ROS repo, that also exist as system packages, for years. If you follow through with this policy, ROS 1 should not have been published in the ROS repos for Ubuntu 18.04 and 20.04 at all, since ROS 1 already exists as system packages (ros-base, ros-desktop, ...).

[nuclearsandwich]

There always have been alternative versions of system packages in the ROS repos, e.g. for OpenCV

Problems maintaining the in-ROS version of OpenCV and conflicts with the system version are part of what informed this policy.

I did not expect this to be suddenly a problem. Especially since the ROS workspace is a separate environment that has to be sourced first.

It's mentioned in https://github.com/ros/rosdistro/blob/master/CONTRIBUTING.md#releasing-third-party-system-packages-into-a-ros-distribution but it's a relatively recent addition (2021) before that it was still part of our review process but addressed when observed on a case-by-case basis.

Having to rely on an outdated library with limited support for cameras for the whole duration of the Ubuntu 22.04 lifetime (5 years) is not promising. Most packages do not even receive that long support. For most packages, support ends after 2~3 years.

I can understand that you do not want to have the very same version in the system and the ROS repos. But for most situations, I don't see the advantage of relying on outdated packages for 5 years.

There is always going to be a trade-off, even with the most mature of packages, between stability and new fixes and features. For the ROS team, which is small and trying to cover a wide breadth of software, we rely on the work done by the communities around our base platforms (Debian, Ubuntu, RHEL + EPEL, etc) to provide as much of the system as possible so that the surface area that is unique to ROS is as tightly focused on ROS packages themselves. To that end, when packages are available for our base platforms, we want to avoid doing the work to integrate other versions of those packages again.

If you follow through with this policy, ROS 1 should not have been published in the ROS repos for Ubuntu 18.04 and 20.04 at all, since ROS 1 already exists as system packages

Our repositories exist to provide stable and up-to-date ROS packages, where "ROS packages" in this case refers to packages which are maintained by the ROS community and build on top of or specifically for the ROS core. For that reason the push toward and preference for upstream does not apply to these ROS packages.

---

I can only speak for libcamera. This is a relatively new library with an unstable API. The version in Ubuntu is already outdated. Having to rely on an outdated library with limited support for cameras for the whole duration of the Ubuntu 22.04 lifetime (5 years) is not promising. Most packages do not even receive that long support. For most packages, support ends after 2~3 years.

The fact that there is no rosdep key at this time is, in my opinion, a decent indicator that few to no people are using this package in ROS at this time. And thus a case could be made for vendoring a "usable" version of this package in ROS distributions on Ubuntu 22.04 but with the expectation that when a comparable version is available upstream the upstream version will be used and that as time goes on the vendor package in ROS would go away entirely rather than continuously moving the goalposts so that the system version is never "adequate".

@tfoote are there any that criteria would unblock a libcamera vendor package on 22.04 for you? I see the appeal in holding hard to policies and would respect it, especially as one of the people responsible for doing the system integration work but I'm also trying to be a pragmatist and make sure that we enable the community to ship useful software.

[tfoote]

In general the main thing that I want to do is not just cause future work for myself or whoever else has to deal with the fallout. It's always easier to just make it work now and discount the upstream package. But in reality the upstream package has a much broader community and user base. And if we just discount and override the package now, at some point in the future the upstream version will catch up and generate a non-trivial user base and at that point we'll be conflicting. And then we'll be the bad actor overriding it and breaking users who install ours on top. And then the question of how many people do we have to break before we have to fix it? In general we should not be doing anything that might break other use cases.

I can only speak for libcamera. This is a relatively new library with an unstable API. The version in Ubuntu is already outdated. Having to rely on an outdated library with limited support for cameras for the whole duration of the Ubuntu 22.04 lifetime (5 years) is not promising. Most packages do not even receive that long support. For most packages, support ends after 2~3 years.

Unfortunately I don't find this argument very compelling. Everything in Ubuntu is typically outdated before it's released. It's a relatively long process to QA things and this means that the development tip is always out front. If you want to use an OS from 2022 that's has a stable API you should use 22.04. You can't expect to have both a stable LTS and the latest and greatest of the specific library of your choice. We hear this all the time that users want everything stable, except for the one library of their choice which they want the newest version. But when you step back and listen to everyone, they all want different libraries upgraded, and to meet all their requests, the platform is no longer stable.

In terms of the support cycle, the debian/Ubuntu maintainers have committed to maintaining it for 5 years. If you have something that won't be supported for more than 2-3 years, it shouldn't be in a ROS release either.

So in general what I think I would suggest is that if this is something that's important to you or a subset of users with you is that you make the effort to package it yourself for your use cases. For yourself and your users they can explicitly opt into overriding the system version. And whether you do this via a PPA or some other mechanism that's not a problem. But we shouldn't force the entire community to make that tradeoff. Optimally you'd be able to make that effort and push it upstream and then people won't have to make that trade-off and we with all the other users will get it by default without a conflict.

[christianrauch]

First of all, thank you for taking the time to give those elaborative answers :-)

It's mentioned in https://github.com/ros/rosdistro/blob/master/CONTRIBUTING.md#releasing-third-party-system-packages-into-a-ros-distribution but it's a relatively recent addition (2021)

Thanks for sharing this, I did not know of this before. The section states that overlaying system packages is allowed if three conditions (install side by side, not cause compile errors, not cause linking errors) are met. For me, this means that libcamera and libapriltag are allowed to be released if they do not conflict with other Debian packages or cause compiler or linker errors. is this correct?

we rely on the work done by the communities around our base platforms

I kind of feel part of the (ROS) community :-) I am not expecting the ROS community to replicate a lot of system packages but I think providing newer versions of packages is justified in some cases.

The motivation to go through all this trouble of creating colcon-meson and releasing libcamera is for the community to have easy access to a camera node that supports a wide spectrum of cameras, including the Raspberry Pi Camera Module. Without a binary release, users will have to compile this from source. This is non-trivial on a Raspberry Pi as you will have to restrict the number of parallel processes in order to not run out of memory, and it generally takes a very long time. As someone who contributes to ROS and its ecosystem for a long time, this is not something that I can propose to someone with good conscience and it also disappoints me to see all this work go to waste.

To that end, when packages are available for our base platforms, we want to avoid doing the work to integrate other versions of those packages again.

I think this just shifts the maintenance costs around. If different distributions provide different incompatible versions of libraries then a developer using these packages has to support every single version separately instead of providing one (newer) version for all the platforms.

---

In general the main thing that I want to do is not just cause future work for myself or whoever else has to deal with the fallout. [...] In general we should not be doing anything that might break other use cases.

I agree that a package released to the ROS repo must not interfere with system packages. But there are many ways to avoid this with versioning. Many distributions even provide multiple versions of libraries that can be installed in parallel themselves (see libsdl and libjpeg in Ubuntu) for many years now without issues. Having multiple versions of the same library is technically possible but of course, requires taking care of the versioning of libraries and include paths.

If you have something that won't be supported for more than 2-3 years, it shouldn't be in a ROS release either.

I do not understand what you mean here. Ubuntu has different support durations for different packages (see https://askubuntu.com/a/870909/704779). It is not 5 years for all packages. Some will only be supported for 3 years. There is no excuse for using outdated packages with functional or security issues.

So in general what I think I would suggest is that if this is something that's important to you or a subset of users with you is that you make the effort to package it yourself for your use cases. For yourself and your users they can explicitly opt into overriding the system version.

I don't understand how this is going to work. If I package a dependency myself, e.g. as a ppa for libcamera, it will not be available to the build server for releasing the camera_ros package that depends on it.

[tfoote]

I agree that a package released to the ROS repo must not interfere with system packages. But there are many ways to avoid this with versioning. Many distributions even provide multiple versions of libraries that can be installed in parallel themselves (see libsdl and libjpeg in Ubuntu) for many years now without issues. Having multiple versions of the same library is technically possible but of course, requires taking care of the versioning of libraries and include paths.

Indeed if the proposed package fully isolated the library such that it wouldn't interfere with packages which were using the system version I would not object, but that wasn't what was proposed here.

I don't understand how this is going to work. If I package a dependency myself, e.g. as a ppa for libcamera, it will not be available to the build server for releasing the camera_ros package that depends on it.

The library is primarily in support of one package. You could host both an upgraded version of libcamera as well as the package for camera_ros which uses it and is compiled for the raspberry pi. Then the users who it enables (aka those raspberry pi camera users) could leverage your build, knowing that they're upgrading libcamera by enabling your repository. And it won't break people in the larger ecosystem that are unaware of this potential breakage who didn't opt into this breaking change/upgrade.

I do not understand what you mean here. Ubuntu has different support durations for different packages (see https://askubuntu.com/a/870909/704779). It is not 5 years for all packages. Some will only be supported for 3 years. There is no excuse for using outdated packages with functional or security issues.

That quote for different support cycles is from long ago. On my LTS distro 20.04 everything from Ubuntu is supported for the life of the distribution. That's the part of being in the distribution, Canonical stands by that.

[🔍NOTFOUND] ❯ ubuntu-security-status 3955 packages installed, of which: 2364 receive package updates with LTS until 4/2025 422 packages are from third parties 6 packages are no longer available for download

[christianrauch]

Indeed if the proposed package fully isolated the library such that it wouldn't interfere with packages which were using the system version I would not object, but that wasn't what was proposed here.

I proposed to release the libcamera library from upstream (https://git.libcamera.org/libcamera/libcamera.git) with a different version, given a different package name and installed in a different environment. I am sure this isolates the ros-$ROS_DISTRO-libcamera package from the system's libcamera0 / libcamera-dev.

system version (Ubuntu 22.04)

The system version uses upstream commit e7aa92a, dated 2020-05-02. That was already 2 years old when Ubuntu 22.04 was released 6 months ago. It installs a pkg-config file /usr/lib/x86_64-linux-gnu/pkgconfig/camera.pc and a soname library /usr/lib/x86_64-linux-gnu/libcamera.so.0.1.0. Hence the library is identified by its name camera and a version encoded shared object libcamera.so.0.1.0.

You can further verify that the headers are installed in the system include folder:

$ pkg-config --cflags camera
-I/usr/include/libcamera

bloom version

A bloomed libcamera version (ros-humble-libcamera, using ros-infrastructure/bloom#691 and a patched package.xml) installs those files to /opt/ros/humble/lib/x86_64-linux-gnu/pkgconfig/libcamera.pc, /opt/ros/humble/lib/x86_64-linux-gnu/libcamera.so.0.0.2 and /opt/ros/humble/include/libcamera. Hence, the package identifies as libcamera instead of camera and libcamera.so.0.0.2 instead of libcamera.so.0.1.0.

Those paths and filenames clearly differ. The bloom and system packages can be installed and used side-by-side.

Do you foresee other ways in which the bloom package ros-humble-libcamera will interfere with the system packages libcamera0 / libcamera-dev?

[tfoote]

That resolves the filesystem layout. But you need to both resolve compile time collisions and runtime collisions.

At compile time, do you export any of the paths to those headers? If so do you do so in a way such that downstream packages would not accidentally find your headers instead of theirs depending on the potential include path order?

For binary isolation have you isolated the binary symbols inside of the libraries such that if someone depends on your packages as well as any other one that happens to link against the system version of libcamera do you know that they won't collide the symbols. This usually requires renamspacing all the symbols in the library.

[christianrauch]

At compile time, do you export any of the paths to those headers? If so do you do so in a way such that downstream packages would not accidentally find your headers instead of theirs depending on the potential include path order?

I am not sure what exporting the header paths means here, but the *.pc files point to different locations for the headers (/usr/include, /opt/ros/humble/include):

$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/camera.pc
prefix=/usr
includedir=${prefix}/include
[...]
Cflags: -I${includedir}/libcamera

and

$ cat /opt/ros/humble/lib/x86_64-linux-gnu/pkgconfig/libcamera.pc
prefix=/opt/ros/humble
includedir=${prefix}/include
[...]
Cflags: -I${includedir}/libcamera

For binary isolation have you isolated the binary symbols inside of the libraries such that if someone depends on your packages as well as any other one that happens to link against the system version of libcamera do you know that they won't collide the symbols. This usually requires renamspacing all the symbols in the library.

Right. If you link both libraries at the same time, this will be problematic for symbols with different implementations.

But where would this happen with libcamera? I don't foresee a use case where a program in the ROS workspace would indirectly link the system libcamera via a dependency and the libcamera version from the ROS repo. In fact, the system's libcamera0 is not used by any other library in the Ubuntu repo (see apt-cache rdepends libcamera0) and hence it is not possible to link the system's libcamera in libcamera0 indirectly. It is only possible to cause linking errors via symbol conflicts at compile time if a user decides to directly link the system and the ROS libcamera at the same time. Hence, there will never be linking issues at runtime.

Can you think of a case where symbol conflicts will happen with the system's libcamera0 package?

Do you have an example where symbol conflicts in a driver library caused issues for ROS before?

[tfoote]

I am not sure what exporting the header paths means here, but the *.pc files point to different locations for the headers (/usr/include, /opt/ros/humble/include):

yes the headers are in different locations. But if you depend on both versions they will both be added to include path of the downstream package. If they have the same file name/path within the Include directory then the one which appears on first in the include search path will override the second one.

It is only possible to cause linking errors via symbol conflicts at compile time if a user decides to directly link the system and the ROS libcamera at the same time. Hence, there will never be linking issues at runtime.

This is not a valid path of logic to know that our users will not hit this case. Just because you don't see anyone depending on it right now in released packages doesn't mean that it's not already a problem in packages that you don't know about. Similarly it doesn't mean that it will not be a problem for the rest of the lifetime of the distribution. And you've only scanned Ubuntu packages, not ROS packages. All packages start as leaf packages in the dependency tree when first released. But if they're useful packages they won't stay that way.

Can you think of a case where symbol conflicts will happen with the system's libcamera0 package?

if this is a rosdep key any package could use the system version. Following that someone else might want to write a dependent package that wants to provide universal camera application (say a little gui to view any camera) So they create a GUI and add dependencies for all the camera drivers they define. And boom it crashes on them with binary inconsistencies.

Do you have an example where symbol conflicts in a driver library caused issues for ROS before?

This was a giant pain with OpenCV and PCL many years ago. We similarly tried to make justifications about why the impact would be minimal and then we had to dig out of a big mess because those cases that were assumed not to happen did and we had to do a lot of work to migrate it such that we found a way to not require packages to be silently fractured into ones that were compatible with the system version or the ROS packaged version.

And it is why we added the rule that we don't end up with silent errors that fragments our communities packages due to incompatibility with other dependencies. All packages are expected to not conflict with any preexisting packages nor system packages, at installation time, compile time, or runtime.

[christianrauch]

Summary:

With the current set of packages in the Ubuntu and ROS repo, it is not possible to cause symbol conflicts with libcamera as no library depends on the system's camera library (package libcamera0). The reason no one is depending on the libcamera0 package is very likely that this package is utterly broken. Every program built with the system package crashes on startup.

If libcamera is added to the ROS repo, it is only possible to cause conflicts if:

1. a third-party source library depends on the system's camera library and a user links this library and the bloomed libcamera package at the same time
2. a package depends on the system's camera library and the bloomed libcamera in parallel

These two problems are compile-time issues that then be resolved by compiling only against the newer libcamera. If you still think someone should use the Ubuntu package, install the package libcamera-tools and run cam -l. This will just segfault.

Even a program as simple as:

#include <libcamera/libcamera.h>
int main(int argc, char **argv) {
    libcamera::CameraManager camera_manager;
}

will segfault in the global constructors even before reaching main.

Given that there is no path to symbol conflicts using the current set of Debian packages in Ubuntu and ROS and that the system version is utterly broken, I am asking for an exemption of this rule for libcamera. I am 99% confident that no one will ever publish a package with the system's camera library as all those programs will just crash.

---

I am not sure what exporting the header paths means here, but the *.pc files point to different locations for the headers (/usr/include, /opt/ros/humble/include):

yes the headers are in different locations. But if you depend on both versions they will both be added to include path of the downstream package. If they have the same file name/path within the Include directory then the one which appears on first in the include search path will override the second one.

I can see this happen when someone imports both packages (camera and libcamera). But this someone would do this consciously in a project and should be aware of complications.

As a counter-example, the libjpeg packages in Ubuntu (libjpeg62-dev, libjpeg8-dev, libjpeg9-dev) are conflicting as they all register as libjpeg via their *.pc file. But this is not the case here, as both libraries use different pkg-config names.

It is only possible to cause linking errors via symbol conflicts at compile time if a user decides to directly link the system and the ROS libcamera at the same time. Hence, there will never be linking issues at runtime.

This is not a valid path of logic to know that our users will not hit this case. Just because you don't see anyone depending on it right now in released packages doesn't mean that it's not already a problem in packages that you don't know about. Similarly it doesn't mean that it will not be a problem for the rest of the lifetime of the distribution. And you've only scanned Ubuntu packages, not ROS packages. All packages start as leaf packages in the dependency tree when first released. But if they're useful packages they won't stay that way.

I scanned all of the registered package repos (Ubuntu + ROS). You can verify this by apt-cache rdepends libopencv-core4.5 which will tell you amongst others that a couple of ros-humble- packages depend on it. In its current state, the combined set of Ubuntu and ROS packages do not use libcamera0 as a dependency in another library a package could depend on. Hence, it is not possible to create such a symbol conflict using packages from both repos.

Symbol conflicts only become a problem if another ROS package depends on the system's camera package and is released to the ROS repo. This hasn't happened yet and this very PR aims at releasing a functioning libcamera version to the ROS repo so that other packages can rely on the newer support for cameras instead of relying on the outdated camera library.

Can you think of a case where symbol conflicts will happen with the system's libcamera0 package?

if this is a rosdep key any package could use the system version. Following that someone else might want to write a dependent package that wants to provide universal camera application (say a little gui to view any camera) So they create a GUI and add dependencies for all the camera drivers they define. And boom it crashes on them with binary inconsistencies.

Do you have an example where symbol conflicts in a driver library caused issues for ROS before?

This was a giant pain with OpenCV and PCL many years ago. We similarly tried to make justifications about why the impact would be minimal and then we had to dig out of a big mess because those cases that were assumed not to happen did and we had to do a lot of work to migrate it such that we found a way to not require packages to be silently fractured into ones that were compatible with the system version or the ROS packaged version.

I fully understand the issues with "utility" libraries, such as OpenCV and PCL. These are used by many libraries, and those libraries are again used by other packages, causing all kinds of conflicts. But I don't think this is the case with "driver" libraries, as those are mostly used directly by programs.

And it is why we added the rule that we don't end up with silent errors that fragments our communities packages due to incompatibility with other dependencies. All packages are expected to not conflict with any preexisting packages nor system packages, at installation time, compile time, or runtime.

Given that the system version is essentially unusable, I doubt that there will fragmentation between the two versions. Why would someone depend on a broken library when they could use the newer working version?

[christianrauch]

@nuclearsandwich @tfoote @sloretz Given that is it practically impossible that someone will use Ubuntu's libcamera package on 22.04 due to the instant crash of any process that will use Ubuntu's libcamera (see above), can I get an exemption from the "no multiple versions, prefer system version" policy for the libcamera package?

According to #35029 (comment), the broken Ubuntu package should be a case for:

One situation where I could see a strong case for including a version of libcamera in ROS in spite of its availability on target platforms is if the version available from the system is unusably broken thus making it unlikely that any ROS package would ever interact with or cross-link with the system library.

[tfoote]

Given that is it practically impossible that someone will use Ubuntu's libcamera package on 22.04 due to the instant crash of any process that will use Ubuntu's libcamera (see above), can I get an exemption from the "no multiple versions, prefer system version" policy for the libcamera package?

Yes this would be a reason that we could consider overriding it on 22.04. Is there an upstream bug about this? Is it expected to be fixed upstream? What is the status of this bug in other distributions?

If we say it's broken enough in 22.04 to consider overriding it that doesn't just give carteblanch for making a release. If we make a release of the ROS package now, what will be the migration plan for all users as we will default to using the system version for future platforms?

[christianrauch]

Is there an upstream bug about this?

I created an upstream bug report at https://bugs.launchpad.net/ubuntu/+source/libcamera/+bug/1999300.

Is it expected to be fixed upstream?

I don't know. This is entirely up to Ubuntu. Given that the package is in "universe" and Ubuntu does not even guarantee regular security updates for those packages (https://help.ubuntu.com/community/Repositories) and my experience with the Eigen3 package in 16.04, I do not have high hopes that this gets fixed in the next 12 months.
Since the package hasn't been updated in 2.5 years and isn't used by any other package, I guess that this package does not have a priority for Ubuntu.

What is the status of this bug in other distributions?

I cannot give a detailed answer here. I am doing all this privately and I do not have an extensive test setup. A quick test on Arch Linux shows me that this works for version 0.2. For other distributions, I simply guess that newer versions do not have this issue. It would be helpful if others with different distributions could try to run the demo program too.

If we say it's broken enough in 22.04 to consider overriding it that doesn't just give carteblanch for making a release. If we make a release of the ROS package now, what will be the migration plan for all users as we will default to using the system version for future platforms?

For releases beyond Ubuntu 22.04 where the system's libcamera works as expected, I suggest that we replace the bloom release with a rosdep key of the same name. This way the package.xml can stay the same. Since this is a "plain" package without ROS dependencies or other wrappers, the CMakeLists.txt and the source could also stay the same, assuming that the libcamera developers do not change the API.

[christianrauch]

@tfoote @nuclearsandwich Is the migration plan for libcamera satisfactory? The idea would be to bloom-release libcamera to Ubuntu 22.04 to provide a working libcamera version because the system version is unusable. For future releases of Ubuntu, which provide working versions of libcamera, we would use a rosdep key referencing the system package.

[christianrauch]

Ubuntu chose to ignore the libcamera issue for 22.04. It is unrealistic that Ubuntu will take the issue seriously and fix it. Releasing libcamera via bloom to the ROS repos is the only way to provide the libcamera dependency to other packages.

@tfoote @nuclearsandwich Could you please reconsider this PR or let me know what other reasons speak against a working version of libcamera for 22.04?

[tfoote]

Ok, so we've confirmed that it won't be fixed.

The migration plan, at a high level goal of what we want to achieve in the migration, for people on 22.04 to use the bloomed version and everyone else to use the system version. And in the long run people use rosdep keys. But a plan needs to be concrete for this case.

If we release into humble and rolling now. That will cover 22.04, is libcamera verified as working on newer versions of Ubuntu? What about Debian and Fedora/RHEL? Does it need to be patched on those?

We likely should be setting this up as a vendor package not a straight package so that it can detect the system version of libcamera and use that one if it's available.

It's not great practice to try to make the rosdep key and package name have the same name as then you will end up with potential collisions and the maintainers can't know what their package will build against and be tested against. And rosdep keys aren't tied to specific distros. They span and potentially break others. We are doing less platform version spanning now but we don't want to rely on that.

And the migration plan needs stories for developers and explicit instructions for what they should do if they're supporting each release. In particular, we need to be able to tell developers on humble and rolling what dependencies to add. And we need to be able to tell them when they should switch to the rosdep key directly. And if developers want a branch to span multiple distros what is possible/best practice. And when will they have to take action on the deprecation of the vendor package for an upstream package.

[christianrauch]

If we release into humble and rolling now. That will cover 22.04, is libcamera verified as working on newer versions of Ubuntu? What about Debian and Fedora/RHEL? Does it need to be patched on those?

From the distributions supported by ROS bloom releases, Ubuntu 22.04 has the broken libcamera version and RHEL 8 does not have a libcamera package at all. Debian 11 also does not have a libcamera package (the search for libcamera returnes unrelated ROS packages).

For future versions, e.g. from Ubuntu 23.04 (lunar) on, the described issue is not present any more. My expectation is that eventually, all major distributions will have a libcamera package without bugs.

We likely should be setting this up as a vendor package not a straight package so that it can detect the system version of libcamera and use that one if it's available.

It's not great practice to try to make the rosdep key and package name have the same name as then you will end up with potential collisions ...

My understanding from such a vendor package, e.g. libyaml_vendor, is that it will have a different package name than the original package and select at compile time if the upstream source version should be compiled or if the system version should be used.

I think using a different package name than what would be used for the rosdep key has a negative impact on the transitioning strategy. As it is now (proposed here), we would have a bloom package with the name libcamera in the case where there is no working libcamera in the distribution (e.g. 22.04). For distributions that have a working libcamera packge, there would simply be a rosdep key of the very same name (libcamera). This way, a dependant package (camera_ros in my case) could use that dependency agnostic to the underlying source (bloom or rosdep). Otherwise, users of the libcamera dependency have to know where to take the dependency from and update the key name depending on the target distribution, making te migration more difficult.

My second point against this is that we already know which distributions have a working version of libcamera. We do not need a compile time selection as we can already decide which distributions get the bloomed version and which one get the rosdep key.

... and the maintainers can't know what their package will build against and be tested against. And rosdep keys aren't tied to specific distros. They span and potentially break others.

As far as I can tell, you can enable/disable distributions and versions for a rosdep key, e.g. as done for libboost-date-time:

rosdistro/rosdep/base.yaml

Lines 2592 to 2607 in 4ffd760

	libboost-date-time:
	debian:
	bullseye: [libboost-date-time1.74.0]
	buster: [libboost-date-time1.67.0]
	fedora: [boost-date-time]
	gentoo: [dev-libs/boost]
	nixos: [boost]
	openembedded: [boost@openembedded-core]
	opensuse: [libboost_date_time1_66_0]
	rhel: [boost-date-time]
	ubuntu:
	bionic: [libboost-date-time1.65.1]
	eoan: [libboost-date-time1.67.0]
	focal: [libboost-date-time1.71.0]
	jammy: [libboost-date-time1.74.0]
	xenial: [libboost-date-time1.58.0]

My proposal is to do the same for a future libcamera rosdep key, which would only be enabled for Ubuntu ludic (23.04) and onwards. There would be no key for Ubuntu jammy (22.04) as this will be covered by the bloom package. Vice versa, there will only be a bloom release for jammy and not for other distributions with a working libcamera.

And the migration plan needs stories for developers and explicit instructions for what they should do if they're supporting each release. In particular, we need to be able to tell developers on humble and rolling what dependencies to add. And we need to be able to tell them when they should switch to the rosdep key directly. And if developers want a branch to span multiple distros what is possible/best practice. And when will they have to take action on the deprecation of the vendor package for an upstream package.

With the motivation of using the same package name and rosdep key, there is no need to switch the key or select which one to use. You simply keep the key in your package.xml. So what I would tell developers is:
"Use the libcamera key in your package.xml. If that key does not exist for a newer distribution, e.g. because there is no rosdep entry or bloom release yet, check if a working version of libcamera is available in the target distribution and send a rosdep PR, or send a request to release the bloom package otherwise."

But as stated above, generally I expect distributions to ship working libcamera versions and that bloom releases are only the fallback option.