[Buildroot] [External] - [PATCH 0/1] libgpiod v2

[Vincent Fazio]

All

> -----Original Message-----
> From: Andreas Naumann <dev at andin.de>
> Sent: Friday, October 20, 2023 9:30 AM
> To: Edgar Bonet <bonet at grenoble.cnrs.fr>; buildroot at buildroot.org;
> Vincent Fazio <vfazio at xes-inc.com>; Arnout Vandecappelle
> (Essensium/Mind) <arnout at mind.be>
> Subject: Re: [Buildroot] [External] - [PATCH 0/1] libgpiod v2
> 
> Hi Vincent, all,
> 
> On 19.10.23 09:34, Edgar Bonet wrote:
> > Hello!
> >
> > On 2023-10-18, about whether the API-breaking libgpiod v2 should be an
> > upgrade or a new package, Arnout Vandecappelle wrote:
> >> If it's like "mostly it will still work, but there are a few
> >> functions that you need to replace with a new variant", then the
> >> proper approach is indeed to fix the packages that fail to build.
> >> [...]
> >>
> >> For bigger API changes [...] we indeed need a new package libgpiod2.
> >
> > I've watched a talk by Bartosz Golaszewski about the new libgpiod,[1]
> > then started looking at the documentation of this new API.[2] My
> > feeling is that this is a quite extensive rewrite. A program wanting
> > to support both the v1 and the v2 APIs would need quite a bit of
> > conditional compilation.
> >
> 
> I've got the same impression and would vote to create libgpiod2 for the same
> reasons Arnout stated. Even if conditional use is possible, it's not that
> straightforward and requiring somebody to implement and possibly
> upstream those for the 4 dependent packages seems like creating a barrier.
> 

This is fine, but it won't be a painless transition. The downside is that libgpiod2
requires Linux 5.10+, so making it a separate package for that purpose makes
sense. But having it be a separate package does complicate other packages
that depend on libgpiod because they will need to be patched to play nice with
both versions either way. And it will not be possible to select libgpiod2 and
those other packages until they have had patches written.

> In addition, i think the behaviour of the tools has changed a bit, e.g.
> after gpioset finishes it returns the GPIO to the original state (at least that's
> what I recall from what Börge told me about it).
> 
> So if people use gpioget/set and so on in scripts, the behaviour most likely
> changes unexpectedly.
> 

IMO, consumers of BR should be reviewing the changelogs and making note of
any version bumps that could impact their workflows and doing the testing to
make sure things still work for their situation.

BR can't be responsible for the eternal backwards compatibility of all of the 
tools it provides.

> @Vincent, do you have the intent or maybe even a patch for creating a
> separate v2 package? Otherwise me/Börge would look into coming up with
> one.
> 

I won't have time to do this any time soon.

> 
> regards,
> Andreas
> > _______________________________________________
> > buildroot mailing list
> > buildroot at buildroot.org
> > https://lists.buildroot.org/mailman/listinfo/buildroot
> >