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

[Kieran Bingham]

Quoting Dylan Aissi (2025-02-19 16:13:28)
> 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.

I guess I could imagine a rootfs with both 32 and 64 bit support but
eeep. Dragons a-plenty... ;-D


> 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 think that's fine. As long as the IPA components are distinctly
separated from the normal system libraries.

 
> > 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 :-)

Awesome, thanks. out of interest,
https://lists.debian.org/debian-devel-announce/2025/01/msg00004.html
lists:

2025-03-15      - Milestone 1 - Transition and toolchain freeze
2025-04-15      - Milestone 2 - Soft Freeze
2025-05-15      - Milestone 3 - Hard Freeze - for key packages and
                                packages without autopkgtests
To be announced - Milestone 4 - Full Freeze

Which of those milestones is the last time a new version of libcamera
will be updated in debian trixie?

> 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].
> 

[3] looks pretty reasonable to me.

--
Kieran


> 
> 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