[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Bartosz Golaszewski]

On Tue, Nov 3, 2020 at 9:25 PM Arnout Vandecappelle <arnout at mind.be> wrote:
>
>
>
> On 30/10/2020 11:53, Bartosz Golaszewski wrote:
> > On Fri, Oct 30, 2020 at 11:41 AM Thomas Petazzoni
> > <thomas.petazzoni at bootlin.com> wrote:
> >>
> >> On Fri, 30 Oct 2020 11:16:04 +0100
> >> Bartosz Golaszewski <brgl at bgdev.pl> wrote:
> >>
> >>>> Well, that is an issue. An application that builds with 1.6 may not
> >>>> build with 1.4, so they are not compatible API-wise, and therefore
> >>>> having libgpiod.mk fall back to 1.4 automatically when the kernel
> >>>> headers are too old is going to potentially break applications that use
> >>>> 1.6-specific APIs.
> >>>
> >>> Versioning of libgpiod just follows the regular MAJOR.MINOR.BUGFIX
> >>> scheme. Major releases break API. Minor releases don't break API but
> >>> (may) introduce new features. Bugfix releases don't change API. I
> >>> think this is the standard for most libraries. So far no buildroot
> >>> package even depends on libgpiod so this could only affect out-of-tree
> >>> users. I'm not sure what the policy here is @buildroot though.
> >>
> >> This is perfectly OK. Where it clashes is when a new MAJOR.MINOR
> >> release drops support for kernels older than 5.5, which is a
> >> super-recent kernel version. This prevents from simply updating to the
> >> latest 1.6 release in all situations, causing a compatibility problem
> >> that is quite annoying to handle.
> >>
> >
> > In that case I would advise to keep v1.4 exclusively in buildroot -
> > just like we do in meta-openembedded.
>
>  But that brings us back to the other problem: any package that relies on the
> new API in 1.6 can't be built.
>
>  I think the only *real* solution for that is to introduce a libgpiod16 package
> if people actually start to use the new APIs. But then we probably end up with
> two copies of libgpiod (1.4 and 1.6) because some packages use don't require the
> new APIs...
>
>  So, this reliance on 5.5 kernel headers is really putting limitations to your
> downstream users.
>

I understand. I will see about downgrading this requirement in the
v1.6.x branch then. Don't introduce this package split just yet.

Bartosz