[libcamera-devel] [PATCH v2 1/2] libcamera: ipa_manager: Only parse IPA modules

[Dylan Aissi]

Hi Kieran and Laurent,

On 2/14/25 17:32, Laurent Pinchart wrote:
> On Fri, Feb 14, 2025 at 10:37:54AM +0000, Kieran Bingham wrote:
>> Hi Dylan,
>>
>>> I don't see a good reason other than trying to make v4l2 and *_ipa_proxy
>>> multiarch co-installable.
>>> Now the question is, does this make sense? I don't know. I can drop the
>>> libexecdir override, both v4l2 and *_ipa_proxy will go back in
>>> usr/libexec/libcamera/
>>> and both binary packages libcamera-v4l2 and libcamera-ipa will no longer
>>> be multiarch co-installable, but I am not sure there was a real use case
>>> anyway.
>>
>> The tricky part here will likely be the IPA proxies. I think that's part
>> of 'libcamera' but could be handled as part of libcamera-ipa indeed, and
>> then that component shouldn't be multiarch - the package itself would be
>> architecture specific. Same for the libcamera-v4l2.
>>
>> Having libcamera core multi-arch facilitates cross compiling which is
>> great. libcamera-v4l2 and libcamera-ipa are not required for that.
>>
>> Are there other use-cases for having multi-arch libcamera?

Yes, for instance if someone wants to install both the arm64 *and* the 
armhf (or any other architecture) variant of the libcamera-ipa package 
on the same system, then it would no longer be possible. Why would 
someone want to do that? For instance, to have a single image that works 
on two different architectures. I've already had to deal with this kind 
of request, but not with libcamera from what I know.

What do you think about using 
usr/libexec/$(DEB_HOST_MULTIARCH)/libcamera/ instead of 
usr/libexec/libcamera/ ? That would keep these packages multi-arch 
co-installable.

> I agree with the reasoning. All components needed at build time should
> come from multiarch packages. Components needed at runtime only (IPA
> modules, IPA proxies, and v4l2-compat.so) don't need to be
> multiarch-compatible as far as I can tell.
> 

>> Will you make an update to the debian packages?

Of course! Especially because the freeze of Debian Trixie is coming [1] 
and I don't want to provide a package of libcamera with bugs in the 
future Debian stable :-)

I have created two merge requests to fix the debian packaging, one 
dropping the override of --libexecdir [2] and the other using 
libexec/$(DEB_HOST_MULTIARCH) to override it [3].


Best regards,
Dylan

[1] https://lists.debian.org/debian-devel-announce/2025/01/msg00004.html
[2] https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/15
[3] https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/16