[libcamera-devel] [PATCH] v4l2: Add soversion to the V4L2 layer

[Kieran Bingham]

Quoting Laurent Pinchart (2023-05-03 13:37:37)
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Wed, May 03, 2023 at 11:01:40AM +0100, Kieran Bingham via libcamera-devel wrote:
> > There may be parallel installations of libcamera with separate
> > instances of the v4l2-adaptation layer shared object.
> 
> For libcamera, absolutely, but for v4l2-compat.so, the use cases seem
> less clear to me.
> 

Because

 LD_PRELOAD='/usr/lib/x86_64-linux-gnu/v4l2-compat.so' firefox

Will load the 'latest' ? most recent? version of libcamera, while:

 LD_PRELOAD='/usr/lib/x86_64-linux-gnu/v4l2-compat.so.0.0.4' firefox

Will explicitly run firefox with libcamera-0.0.4, and 

 LD_PRELOAD='/usr/lib/x86_64-linux-gnu/v4l2-compat.so.0.0.5' firefox

will explicitly use libcamera 0.0.5.

If a system has both 0.0.4 and 0.0.5 installed, I could certainly see
reason to be able to test/validate against both. (And of course the
version numbers could be further apart than a single release).


Specifically because we update the soname of libcamera (on every release
presently), it means each v4l2-compat.so is *only* compatible with the
matching libcamera.



> As discussed on IRC, versioning a library's SONAME is meant for two
> purposes as far as I understand: ABI stability for applications linking
> to the library, and installing multiple versions of the library side by
> side. The first purpose doesn't apply to v4l2-compat.so as nothing will
> link to it.
> 
> The second purpose could be applicable, but it seems that the use cases
> would be a bit far-fetched. To support this properly, you would want to
> also support installing multiple versions of libcamerify side by side.

'libcamerify' would take the latest (Equivalent to
LD_PRELOAD='/usr/lib/x86_64-linux-gnu/v4l2-compat.so') and if someone
wants to use a specific version they can LD_PRELOAD it themselves. At
that point it would be more likely they know what they're doing anyway.

> This discussion and patch stem from a Fedora packaging rule that forbids
> unversioned shared object libraries in $libdir/ for non -devel packages.
> Maybe the patch you sent to move v4l2-compat.so to $libdir/libcamera
> could be enough to satisfy the packaging rules, without needing to
> version v4l2-compat.so ? Btw, Javier mentioned on IRC it should actually
> go to $libexecdir/libcamera, but let's discuss that in the review of
> your other patch.

It sounds like you're on the Nack side. Do you actively object to this
because you see harm in versioning the sofile?

Even if we move it to libexec, or lib/libcamera/ or anywhere else, I
can't see why it can not be versioned the same as libcamera.


--
Kieran


> > This shared library can be linked against a specific libcamera
> > soversion so provide a soversioned V4L2 compatibility layer.
> > 
> > Suggested-by: Javier Martinez Canillas <javierm at redhat.com>
> > Signed-off-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
> > ---
> >  src/v4l2/meson.build | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/src/v4l2/meson.build b/src/v4l2/meson.build
> > index f132103cb503..48f201c5c3a0 100644
> > --- a/src/v4l2/meson.build
> > +++ b/src/v4l2/meson.build
> > @@ -30,6 +30,7 @@ v4l2_compat_cpp_args = [
> >  v4l2_compat = shared_library('v4l2-compat',
> >                               v4l2_compat_sources,
> >                               name_prefix : '',
> > +                             soversion : libcamera_soversion,
> >                               install : true,
> >                               dependencies : [libcamera_private, libdl],
> >                               cpp_args : v4l2_compat_cpp_args)
> 
> -- 
> Regards,
> 
> Laurent Pinchart