Re: [libgpiod] Feedback from the Raspberry Pi community

[Kent Gibson <warthog618@xxxxxxxxx>]

On Fri, Jan 12, 2024 at 11:22:17AM +0100, Bartosz Golaszewski wrote:
> On Fri, Jan 12, 2024 at 7:32 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> >
> >
> > I agree with that.  I've raised it before and again now.
> > Having an interactive website of some form would improve community
> > engagement enormously.
> > I'm not sure what form that should take, and I'm not suggesting moving
> > the primary repo from kernel.org or changing the development process,
> > but I don't see how, say, having a github mirror that could double as
> > the community engagement hub could hurt.
> > (ok, on second thought after re-reading that, I can see how that
> > **could** hurt, but I was thinking in terms of increasing engagement, not
> > having to deal with some of the cr*p that would inevitibly land there.)
> >
> > Anything that would help address the misunderstandings,
> > misinformation, and outright propaganda I've seen out there can only be
> > a good thing, right :-| ?
> >
>
> I see. While I prefer using the mailing list as the single point for
> discussion and development, I understand that this opinion is not
> shared by the majority of user-space developers out there. I will
> reopen the original github repo[1] for reporting issues. Possibly for
> sending PRs as well for initial discussion but I'd prefer to pass all
> patches going into libgpiod by the mailing list anyway in the end.
>

Great. And that is what I meant by maintaining the development process -
patches still go via the list, not pull-requests.

Can we update the README to reference that?

> > Either way, the Raspberry Pi devs appreciate that v2 would be preferable
> > and appear interested in packaging libgpiod v2 themselves, rather
> > than waiting for Debian, and IIUC are looking into doing that.
> > They currently package libgpiod2 (libgpiod v1.6.3) and gpiod (libgpiod
> > tools v1.6.3).  I figure they can add a libgpiod3 package (libgpiod
> > v2.1) so they can install both library versions at once.  Wrt the tools,
> > update gpiod to contain the new tools and depend on libgpiod3, and allow
> > the user to pick which rev of the gpiod package they want to install, if
> > they want to support v1 or v2.
> > Requiring both versions of the tools seems like an extreme corner case
> > to me, and could be handled by having the user download, build and install
> > v1.6.3 into a non-standard location.  Alternatively they can package
> > them independently and rename the binaries from one...
> >
> > I don't think there is anything we need to do here, and with any luck
> > this will be resolved in the near future.  Maybe just keep an eye on it.
> >
>
> I am very bad with distros. I have no idea how debian or red hat
> packaging works (other than being a somewhat "advanced" user) and I
> just let distro maintainers handle packaging of libgpiod. For my own
> work I rely 100% on yocto and so keep the relevant recipes in
> meta-openembedded up to date but that's all I have time for. So there
> will be no help from my side on the debian packages. I just don't care
> enough.
>

I've created packages for both at some point, but never as part of
a distro, so I've got a rough idea how the packages themselves work but
no idea how the distro packagers select what goes where or when.
As with you - not something I've ever needed to have a concern for.

> >
> > The solution there is the dbus daemon. That would allow them to perform
> > random sets and gets on arbitrary lines on a whim, just like they do now.
> > They seem very open to that option, both the Pi devs and end users, so the
> > sooner the daemon can be available the better.
> >
>
> I know. I'm half-way done with the locking rework for GPIOLIB and the
> daemon is next on my TODO list. I'm estimating I'm 2/3 done with the
> needed functionality.
>

Let me know if there is anything I can do to help out.

Cheers,
Kent.