Re: [ANNOUNCE] libgpiod v1.6 released

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Fri, Oct 2, 2020 at 4:48 PM Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:
>
> On Fri, Oct 2, 2020 at 10:25 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> > On Thu, Oct 1, 2020 at 4:56 PM Andy Shevchenko
> > <andy.shevchenko@xxxxxxxxx> wrote:
>
> > > > 1. Switch the major version of libgpiod API to 2 and start working on
> > > > the new API (preferably starting out by simply porting the current
> > > > library to v2 uAPI).
> > > > 2. Indefinitely support v1.6.x branch with bug fixes.
> > > > 3. Consider v1.4.x as an LTS supported for as long as yocto uses v5.4
> > > > kernel as their LTS (this is because v1.4 is the last version to not
> > > > require v5.5 kernel headers to build).
> > > > 4. (maybe) Create a compatibility layer between v1.x and v2.x once
> > > > v2.0 is out that will ease the switch to the new release.
> > >
> > > I'm wondering if you are planning to develop v2.x with possibility to
> > > coexist with v1 on the same machine (like gtk2 / gtk3 and other
> > > examples).
> > >
> >
> > Personally I would prefer to avoid doing this. This isn't a very big
> > library so unlike gstreamer or gtk I think it won't take much to
> > switch to v2.0. If anything - I prefer a compatibility layer included
> > in the package where - if an option is passed to configure - the old
> > header would be installed alongside the v2.0 .so file + another .so
> > for translating the calls.
> >
> > If you see a very good reason to make them both live together - let me know.
>
> Aspects that come to my mind, that needs to be taken into account are
> the following:
>  - would ABI be kept on a library level (will binary built against v1
> be capable to run on v2)?

No, of course it won't be kept. This is the whole point of a new major release.

>  - would API be kept compatible (seems so according to Kent's patch)?
>

Same as above. The new major release will need a new API to support
new functionalities introduced by Kent.

> Main point that users that have compiled something for older kernel to
> work should be able to run this on newer distribution environments
> (like one, that would have only v2 of the library).
>

This has nothing to do with the kernel - nobody is changing the kernel
API v1 and it'll be supported by libgpiod v1.6.

In user-space, libraries only guarantee binary compatibility in
respect to the major ABI version. We've already changed the ABI in
libgpiod twice (it's at 2.x.y currently).

I personally don't care much about how desktop distros handle this -
I'm mostly interested in bespoke embedded distros built with yocto or
buildroot. I'm Cc'ing SZ Lin who maintains the libgpiod debian
package.

SZ Lin: libgpiod will get a new major release in the following months
- the API will become v2.x and ABI v3.x - do you think it's important
to make it possible for two major versions of libgpiod to live
together in a single system? I would like to avoid having to rename
everything and use libgpiod2.0 everywhere - this information is
already stored in the API version. Does debian support something like
yocto's virtual providers maybe? How do you see this for a desktop
distro.

Best regards,
Bartosz Golaszewski