add libcamera

[christianrauch]

https://libcamera.org

"A complex camera support library for Linux, Android, and ChromeOS"

Please add the following dependency to the rosdep database.

Package name:

libcamera

Package Upstream Source:

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

Purpose of using this:

The purpose of libcamera is to provide a camera stack that is supported by the industry. See https://libcamera.org for details.

Distro packaging links:

Links to Distribution Packages

• Debian: https://packages.debian.org/
  • https://packages.debian.org/sid/libcamera-dev
• Ubuntu: https://packages.ubuntu.com/
  • https://packages.ubuntu.com/impish/libcamera-dev
• Fedora: https://src.fedoraproject.org/browse/projects/
  • https://src.fedoraproject.org/rpms/libcamera
• NixOS/nixpkgs: https://search.nixos.org/packages
  • https://search.nixos.org/packages?channel=unstable&show=libcamera&from=0&size=50&sort=relevance&type=packages&query=libcamera

[jacobperron]

Can you point to this package, I can't find it.

[christianrauch]

I found it here: http://gpo.zugaina.org/media-libs/libcamera.

[christianrauch]

This is also available on Raspbian (a.k.a. "Raspberry Pi OS"). But I could not use debian for this because it is not available on the "desktop" Debian. Is there a special distro key for Raspbian?

[clalancette]

This is also available on Raspbian (a.k.a. "Raspberry Pi OS"). But I could not use debian for this because it is not available on the "desktop" Debian. Is there a special distro key for Raspbian?

No, all packages in rosdep have to be available in the "main" repositories for the respective distributions (this usually includes "main", "universe", and "multiverse" in Debian/Ubuntu).

Since we don't currently have Raspbian separated from Debian, we can't add rosdep keys for Raspbian-specific packages. One way around this would be to make Raspbian a totally separate OS, but that means a lot of duplication of keys. I'm not sure of the best way forward here. @cottsay @nuclearsandwich any thoughts?

[christianrauch]

In the meantime, I create a "cmake wrapper" package to build libcamera from source. This will allow using libcamera on a wider range of platforms and also use the most recent upstream version.

This package will be called libcamera too. Will there be a conflict between the rosdep definition and the libcamera package, when this gets eventually "bloomed"?

[clalancette]

This package will be called libcamera too. Will there be a conflict between the rosdep definition and the libcamera package, when this gets eventually "bloomed"?

Yes, definitely. When we've "wrapped" packages in the past, we've tended to call them libcamera_vendor, to be clear that we are explicitly vendoring the package. That will avoid the conflict.

[christianrauch]

When we've "wrapped" packages in the past, we've tended to call them libcamera_vendor, to be clear that we are explicitly vendoring the package. That will avoid the conflict.

I was hoping that by giving them the same name/key, it will automatically resolve to either the bloomed packages, or if not available, use the rosdep dependencies. Using different "keys" for the distribution package in the rosdep or the bloomed package makes it necessary to change the manifest, depending on where the ROS package is build. E.g. an old Ubuntu version will need the bloomed package and a newer Ubuntu version may be able to use the distributed Ubuntu package.

If using the same "key" in a rosdep and a bloomed package will break things, I am going to close this request and send a new one for the libcamera build dependencies.

[cottsay]

Since we don't currently have Raspbian separated from Debian, we can't add rosdep keys for Raspbian-specific packages. One way around this would be to make Raspbian a totally separate OS, but that means a lot of duplication of keys. I'm not sure of the best way forward here.

We discussed this briefly in the infrastructure meeting, and your analysis is right. As it stands, the only way to have Raspbian-specific rules would be to stand up a raspbian OS key and duplicate all of the debian rules, which would be pretty awful. There are grounds for a technical investment in cascading rosdep rules so that Raspbian could have its own rules but inherit debian implicitly, but there are drawbacks, of course, It's something that would probably require an amendment to REP 111.

Using different "keys" for the distribution package in the rosdep or the bloomed package makes it necessary to change the manifest, depending on where the ROS package is build. E.g. an old Ubuntu version will need the bloomed package and a newer Ubuntu version may be able to use the distributed Ubuntu package.

This is all true. Our existing *_vendor packages typically check for the system package and "no-op" if it is available.

But I could not use debian for this because it is not available on the "desktop" Debian.

As I'm reading it, libcamera is indeed available for Debian, just not in any of the stable versions. Looks like Fedora is in the same boat - it's only available in the "next" version. This leads me to believe that it will eventually be available widespread and not just in Raspbian - but Raspbian made it available in a stable release earlier than Debian/Ubuntu/Fedora/etc did.

[ivanpauno]

Based on the last comments, it seems to me that we should close this until the package gets released in a stable debian distribution.
@clalancette @cottsay does that sound correct?

[clalancette]

I don't see a viable way forward in this PR right now, so I would say we should close it. @christianrauch do you agree?

[christianrauch]

I don't see a viable way forward in this PR right now, so I would say we should close it. @christianrauch do you agree?

I am in the process of getting the dependencies for building libcamera merged. I wanted to wait until all of them are merged and libcamera can be built in CI just by using the rosdep keys, but I can already close it now. I do not intend to go forward with this since the package is not available on all platforms and its API changes quickly anyway.