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

Bartosz Golaszewski brgl at bgdev.pl
Mon Nov 30 20:31:59 UTC 2020


On Tue, Nov 3, 2020 at 9:56 PM Bartosz Golaszewski <brgl at bgdev.pl> wrote:
>
> 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

Thomas,

I made a new release that redefines needed symbols if building on
linux pre v5.5. I'm wondering though: what is the correct approach for
C libraries if certain kernel uAPI symbols are missing? Redefine them
or just live with ifdefs in the code?

Bartosz


More information about the buildroot mailing list