| Message ID | 20201029110632.25856-1-buildroot@heine.tech |
|---|---|
| State | Superseded |
| Headers | show |
| Series | package/libgpiod: bump version to 1.6 | expand |
Hello Michael, On Thu, 29 Oct 2020 12:06:33 +0100 Michael Nosthoff via buildroot <buildroot@busybox.net> wrote: > -LIBGPIOD_VERSION = 1.4.1 > +# starting with 1.5 libgpiod depends on Headers >= 5.5 > +ifeq ($(BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_5),y) > +LIBGPIOD_VERSION = 1.6 > +else > +LIBGPIOD_VERSION = 1.4.4 > +endif Hum, this is a bit annoying. And upstream is not willing to have proper conditional logic to keep supporting kernels older than 5.5 ? 5.5 is not that old, it seems odd to so quickly drop support. Even 5.4 is the current LTS kernel ! Thomas
Hi, On Thursday, October 29, 2020 13:50 CET, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hum, this is a bit annoying. And upstream is not willing to have proper > conditional logic to keep supporting kernels older than 5.5 ? 5.5 is > not that old, it seems odd to so quickly drop support. Even 5.4 is the > current LTS kernel ! At least that's how I interpret this comment in the NEWS for 1.5 [0]: - added support for bias flags which are a new functionality first available in linux v5.5; subsequently the library now requires v5.5 kernel headers to build; But maybe Bartosz can clarify on this, as he basically is the "upstream" :) Regards, Michael [0] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/NEWS
On Thu, Oct 29, 2020 at 2:06 PM Michael Nosthoff <buildroot@heine.tech> wrote: > > Hi, > > On Thursday, October 29, 2020 13:50 CET, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > > > > Hum, this is a bit annoying. And upstream is not willing to have proper > > conditional logic to keep supporting kernels older than 5.5 ? 5.5 is > > not that old, it seems odd to so quickly drop support. Even 5.4 is the > > current LTS kernel ! > > At least that's how I interpret this comment in the NEWS for 1.5 [0]: > > - added support for bias flags which are a new functionality first available in > linux v5.5; subsequently the library now requires v5.5 kernel headers to > build; > > But maybe Bartosz can clarify on this, as he basically is the "upstream" :) > > > Regards, > Michael > > [0] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/NEWS > Hi Thomas! I don't want to have an ifdef hell in libgpiod depending on symbol presence/kernel version. I much better prefer to support multiple stable branches. v1.4.x will be supported for as long as linux v5.4 is supported. That being said: libgpiod only requires the v5.5 headers to build. It will still work on older kernels unless someone uses features that aren't supported. Bartosz
On Thu, 29 Oct 2020 14:06:45 +0100 "Michael Nosthoff" <buildroot@heine.tech> wrote: > At least that's how I interpret this comment in the NEWS for 1.5 [0]: > > - added support for bias flags which are a new functionality first available in > linux v5.5; subsequently the library now requires v5.5 kernel headers to > build; > > But maybe Bartosz can clarify on this, as he basically is the "upstream" :) Wow, actually things are even worse. The latest upstream commit goes like this: treewide: make linux v5.10 a hard requirement for libgpiod The library now uses v2 of the GPIO uAPI. The new user interface is scheduled for release as part of linux v5.10. Linux v5.10-rc1 is now tagged so make v5.10 headers a requirement for the build and update all tests to check for the correct version. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> So a userspace package requires a not-even released Linux kernel version, without backward compatibility for older kernel versions. This seems like a really really odd decision from upstream :-/ Thomas
On Thu, Oct 29, 2020 at 2:13 PM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > On Thu, 29 Oct 2020 14:06:45 +0100 > "Michael Nosthoff" <buildroot@heine.tech> wrote: > > > At least that's how I interpret this comment in the NEWS for 1.5 [0]: > > > > - added support for bias flags which are a new functionality first available in > > linux v5.5; subsequently the library now requires v5.5 kernel headers to > > build; > > > > But maybe Bartosz can clarify on this, as he basically is the "upstream" :) > > Wow, actually things are even worse. The latest upstream commit goes > like this: > > treewide: make linux v5.10 a hard requirement for libgpiod > > The library now uses v2 of the GPIO uAPI. The new user interface is > scheduled for release as part of linux v5.10. Linux v5.10-rc1 is now > tagged so make v5.10 headers a requirement for the build and update > all tests to check for the correct version. > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > So a userspace package requires a not-even released Linux kernel > version, without backward compatibility for older kernel versions. This > seems like a really really odd decision from upstream :-/ > Thomas, This is the master branch - it's not meant for being deployed in distros - this is what stable branches are for. We now have a new ABI in linux and libgpiod has just started a new release cycle that will break the API and ABI of the library - hence the version bump to v2.0 from v1.6 - in order to use new kernel features. v2.0 of libgpiod will no longer support older kernels but I'll support v1.6 indefinitely for older kernels and v1.4 as long as v5.4 is supported. Bartosz
Hi, On Thursday, October 29, 2020 14:41 CET, Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > v2.0 of libgpiod will no longer support older kernels but I'll support > v1.6 indefinitely for older kernels and v1.4 as long as v5.4 is > supported. Will 1.4.x still work with 5.10 kernels? I guess the old API will just be deprecated for a while? So I guess we have two possibilities going forward: - Use the version switch I proposed and even extend it when 2.0 and headers 5.10 are released or - Stay on the 1.4.x branch until linux 5.5 is the oldest supported version (if this is possible). Regards, Michael
Hello, On Fri, 30 Oct 2020 08:53:18 +0100 "Michael Nosthoff" <buildroot@heine.tech> wrote: > Will 1.4.x still work with 5.10 kernels? I guess the old API will > just be deprecated for a while? > > So I guess we have two possibilities going forward: > > - Use the version switch I proposed and even extend it when 2.0 and > headers 5.10 are released or > - Stay on the 1.4.x branch until linux 5.5 is the oldest supported > version (if this is possible). What worries a bit with supporting both 1.4 and 1.6, and in the future say 1.4, 1.6 and 2.0 is that newer versions are likely to introduce new APIs. Applications may rely on such new APIs. When the kernel headers are recent enough, a recent version of libgpiod will be used, and such applications will build properly. But as soon as soon builds a system with older kernel headers, libgpiod will downgrade to an older version, providing potentially less APIs, and therefore breaking any application using them. This strategy of not supporting older kernels in newer versions of libgpiod also means that libgpiod should not introduce any new public API... Otherwise the maintenance burden that libgpiod avoids by not supporting older kernels is a maintenance burden that will fall on the shoulders of users of libgpiod, who will have to make conditional switches depending on whether libgpiod 1.4, 1.6 or 2.0 is used. I am still highly doubtful of the strategy chosen by upstream libgpiod here. Best regards, Thomas Petazzoni
On Fri, Oct 30, 2020 at 8:53 AM Michael Nosthoff <buildroot@heine.tech> wrote: > > Hi, > > On Thursday, October 29, 2020 14:41 CET, Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > v2.0 of libgpiod will no longer support older kernels but I'll support > > v1.6 indefinitely for older kernels and v1.4 as long as v5.4 is > > supported. > > Will 1.4.x still work with 5.10 kernels? I guess the old API will just be deprecated for a while? > Yes! Newer kernels won't break older versions of the library. > So I guess we have two possibilities going forward: > > - Use the version switch I proposed and even extend it when 2.0 and headers 5.10 are released > or > - Stay on the 1.4.x branch until linux 5.5 is the oldest supported version (if this is possible). > > Regards, > Michael > I'd say: stay on v1.4.x branch until the end of v5.4 LTS and then introduce v2.0 as soon as it's available just like there's gstreamer(0) and gstreamer1.0. Bartosz
On Fri, Oct 30, 2020 at 9:19 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello, > > On Fri, 30 Oct 2020 08:53:18 +0100 > "Michael Nosthoff" <buildroot@heine.tech> wrote: > > > Will 1.4.x still work with 5.10 kernels? I guess the old API will > > just be deprecated for a while? > > > > So I guess we have two possibilities going forward: > > > > - Use the version switch I proposed and even extend it when 2.0 and > > headers 5.10 are released or > > - Stay on the 1.4.x branch until linux 5.5 is the oldest supported > > version (if this is possible). > > What worries a bit with supporting both 1.4 and 1.6, and in the future > say 1.4, 1.6 and 2.0 is that newer versions are likely to introduce new > APIs. Applications may rely on such new APIs. When the kernel headers > are recent enough, a recent version of libgpiod will be used, and such > applications will build properly. But as soon as soon builds a system > with older kernel headers, libgpiod will downgrade to an older version, > providing potentially less APIs, and therefore breaking any application > using them. > In yocto this can be handled by providing multiple versions of a package and then making any recipes that need it depend on at-least certain version of it - is buildroot capable of doing something like this? > This strategy of not supporting older kernels in newer versions of > libgpiod also means that libgpiod should not introduce any new public > API... Otherwise the maintenance burden that libgpiod avoids by not > supporting older kernels is a maintenance burden that will fall on the > shoulders of users of libgpiod, who will have to make conditional > switches depending on whether libgpiod 1.4, 1.6 or 2.0 is used. > I don't entirely agree. v1.6 is backward compatible with v1.4 (API- and ABI-wise) - programs linked against v1.4 will work with v1.6. v1.6 will still work with older kernels (granted it's built with v5.5 headers) but any operations that require new kernel features will simply fail at the kernel level. If users don't use these new features, the library works the same. The whole goal of developing a new major release (v2.0) is to rework the public API entirely and also use uAPI v2. Otherwise it would be impossible to support new kernel features. This kind of API breakage has been done by many projects: look at gtk2 & gtk3, gstreamer0 and gstreamer1, python2 and python3 and probably many others. And libgpiod is a rather small library with not many reverse dependencies so far. Libgpiod v2.0 will use the new kernel uAPI and thus require at least the kernel version where this uAPI first appeared. Just like libgpiod v1.x won't work with kernels pre v4.6, libgpiod v2.x won't work with kernels pre v5.10. I don't see how that's a problem. > I am still highly doubtful of the strategy chosen by upstream libgpiod > here. > I think you're overestimating the impact here. For now the master branch moves forward towards a stable v2.0 API. Users are definitely not encouraged to use it ATM. v1.4 and v1.6 are the currently supported stable branches. v1.4 builds and works with linux v4.6. v1.6 builds with linux v5.5 but still works with v4.6 unless the user calls new functions (set_config, bias flags, etc.) where it will fail at run-time but older user programs can still link against it. Let me know if I'm missing something but I really prefer to avoid an ifdef hell and QA mess with supporting earlier kernels with v2.0. Best regards, Bartosz Golaszewski
Hello Bartosz, On Fri, 30 Oct 2020 09:42:01 +0100 Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > What worries a bit with supporting both 1.4 and 1.6, and in the future > > say 1.4, 1.6 and 2.0 is that newer versions are likely to introduce new > > APIs. Applications may rely on such new APIs. When the kernel headers > > are recent enough, a recent version of libgpiod will be used, and such > > applications will build properly. But as soon as soon builds a system > > with older kernel headers, libgpiod will downgrade to an older version, > > providing potentially less APIs, and therefore breaking any application > > using them. > > In yocto this can be handled by providing multiple versions of a > package and then making any recipes that need it depend on at-least > certain version of it - is buildroot capable of doing something like > this? No, what we typically do is have separate packages for libraries which have major versions with significantly different APIs. > I don't entirely agree. v1.6 is backward compatible with v1.4 (API- > and ABI-wise) - programs linked against v1.4 will work with v1.6. v1.6 > will still work with older kernels (granted it's built with v5.5 > headers) but any operations that require new kernel features will > simply fail at the kernel level. If users don't use these new > features, the library works the same. > > The whole goal of developing a new major release (v2.0) is to rework > the public API entirely and also use uAPI v2. Otherwise it would be > impossible to support new kernel features. This kind of API breakage > has been done by many projects: look at gtk2 & gtk3, gstreamer0 and > gstreamer1, python2 and python3 and probably many others. And libgpiod > is a rather small library with not many reverse dependencies so far. > > Libgpiod v2.0 will use the new kernel uAPI and thus require at least > the kernel version where this uAPI first appeared. Just like libgpiod > v1.x won't work with kernels pre v4.6, libgpiod v2.x won't work with > kernels pre v5.10. I don't see how that's a problem. > > > I am still highly doubtful of the strategy chosen by upstream libgpiod > > here. > > > > I think you're overestimating the impact here. For now the master > branch moves forward towards a stable v2.0 API. Users are definitely > not encouraged to use it ATM. v1.4 and v1.6 are the currently > supported stable branches. v1.4 builds and works with linux v4.6. v1.6 > builds with linux v5.5 but still works with v4.6 unless the user calls > new functions (set_config, bias flags, etc.) where it will fail at > run-time but older user programs can still link against it. > > Let me know if I'm missing something but I really prefer to avoid an > ifdef hell and QA mess with supporting earlier kernels with v2.0. I think as long as there's really a 1.x series that is entirely API compatible, and then another 2.x series that is entirely API compatible, but different than 1.x, then it's fine indeed. We can use the 1.4/1.6 conditional in libgpiod.mk, as 1.4 and 1.6 are guaranteed to offer the same API to users of the libraries. And once libgpiod2 is out, we'll have a separate libgpiod2.mk. Would that work ? If so, then it's fine for me. Thanks for explaining your strategy. It's great to have upstream directly on-board in these discussions! Best regards, Thomas
On Fri, Oct 30, 2020 at 10:16 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello Bartosz, > > On Fri, 30 Oct 2020 09:42:01 +0100 > Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > What worries a bit with supporting both 1.4 and 1.6, and in the future > > > say 1.4, 1.6 and 2.0 is that newer versions are likely to introduce new > > > APIs. Applications may rely on such new APIs. When the kernel headers > > > are recent enough, a recent version of libgpiod will be used, and such > > > applications will build properly. But as soon as soon builds a system > > > with older kernel headers, libgpiod will downgrade to an older version, > > > providing potentially less APIs, and therefore breaking any application > > > using them. > > > > In yocto this can be handled by providing multiple versions of a > > package and then making any recipes that need it depend on at-least > > certain version of it - is buildroot capable of doing something like > > this? > > No, what we typically do is have separate packages for libraries which > have major versions with significantly different APIs. > > > I don't entirely agree. v1.6 is backward compatible with v1.4 (API- > > and ABI-wise) - programs linked against v1.4 will work with v1.6. v1.6 > > will still work with older kernels (granted it's built with v5.5 > > headers) but any operations that require new kernel features will > > simply fail at the kernel level. If users don't use these new > > features, the library works the same. > > > > The whole goal of developing a new major release (v2.0) is to rework > > the public API entirely and also use uAPI v2. Otherwise it would be > > impossible to support new kernel features. This kind of API breakage > > has been done by many projects: look at gtk2 & gtk3, gstreamer0 and > > gstreamer1, python2 and python3 and probably many others. And libgpiod > > is a rather small library with not many reverse dependencies so far. > > > > Libgpiod v2.0 will use the new kernel uAPI and thus require at least > > the kernel version where this uAPI first appeared. Just like libgpiod > > v1.x won't work with kernels pre v4.6, libgpiod v2.x won't work with > > kernels pre v5.10. I don't see how that's a problem. > > > > > I am still highly doubtful of the strategy chosen by upstream libgpiod > > > here. > > > > > > > I think you're overestimating the impact here. For now the master > > branch moves forward towards a stable v2.0 API. Users are definitely > > not encouraged to use it ATM. v1.4 and v1.6 are the currently > > supported stable branches. v1.4 builds and works with linux v4.6. v1.6 > > builds with linux v5.5 but still works with v4.6 unless the user calls > > new functions (set_config, bias flags, etc.) where it will fail at > > run-time but older user programs can still link against it. > > > > Let me know if I'm missing something but I really prefer to avoid an > > ifdef hell and QA mess with supporting earlier kernels with v2.0. > > I think as long as there's really a 1.x series that is entirely API > compatible, and then another 2.x series that is entirely API > compatible, but different than 1.x, then it's fine indeed. > > We can use the 1.4/1.6 conditional in libgpiod.mk, as 1.4 and 1.6 are > guaranteed to offer the same API to users of the libraries. > Unless the users use symbols that only first appeared in v1.6. v1.4 is compatible with v1.6 (v1.6 doesn't change/remove any symbols), not the other way around (v1.6 added new symbols). > And once libgpiod2 is out, we'll have a separate libgpiod2.mk. > > Would that work ? > I think so. Just please note that SONAME of libgpiod right now is libgpiod.so.2 because of an ABI change early in the development. So SONAME for libgpiod2 will actually be libgpiod.so.3 - nothing we can do about it I'm afraid. I'll surely guarantee ABI and API stability over all minor releases of v2.x series. > If so, then it's fine for me. > > Thanks for explaining your strategy. It's great to have upstream > directly on-board in these discussions! > Sure! One thing I forgot to mention: I actually consider writing a compatibility layer for libgpiod - a one that would allow users to link against the compatibility library as if they were using libgpiod v1.x but it would actually translate the calls to libgpiod v2.x. Something that libusb did. Bartosz
On Fri, 30 Oct 2020 10:25:37 +0100 Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > We can use the 1.4/1.6 conditional in libgpiod.mk, as 1.4 and 1.6 are > > guaranteed to offer the same API to users of the libraries. > > > > Unless the users use symbols that only first appeared in v1.6. v1.4 is > compatible with v1.6 (v1.6 doesn't change/remove any symbols), not the > other way around (v1.6 added new symbols). 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. > I think so. Just please note that SONAME of libgpiod right now is > libgpiod.so.2 because of an ABI change early in the development. So > SONAME for libgpiod2 will actually be libgpiod.so.3 - nothing we can > do about it I'm afraid. I'll surely guarantee ABI and API stability > over all minor releases of v2.x series. That is fine. Thomas
On Fri, Oct 30, 2020 at 10:34 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > On Fri, 30 Oct 2020 10:25:37 +0100 > Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > We can use the 1.4/1.6 conditional in libgpiod.mk, as 1.4 and 1.6 are > > > guaranteed to offer the same API to users of the libraries. > > > > > > > Unless the users use symbols that only first appeared in v1.6. v1.4 is > > compatible with v1.6 (v1.6 doesn't change/remove any symbols), not the > > other way around (v1.6 added new symbols). > > 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. Bartosz
On Fri, 30 Oct 2020 11:16:04 +0100 Bartosz Golaszewski <brgl@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. Thomas
On Fri, Oct 30, 2020 at 11:41 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > On Fri, 30 Oct 2020 11:16:04 +0100 > Bartosz Golaszewski <brgl@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. Bartosz
On 30/10/2020 11:53, Bartosz Golaszewski wrote: > On Fri, Oct 30, 2020 at 11:41 AM Thomas Petazzoni > <thomas.petazzoni@bootlin.com> wrote: >> >> On Fri, 30 Oct 2020 11:16:04 +0100 >> Bartosz Golaszewski <brgl@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. Regards, Arnout
On Tue, Nov 3, 2020 at 9:25 PM Arnout Vandecappelle <arnout@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@bootlin.com> wrote: > >> > >> On Fri, 30 Oct 2020 11:16:04 +0100 > >> Bartosz Golaszewski <brgl@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
On Tue, Nov 3, 2020 at 9:56 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Tue, Nov 3, 2020 at 9:25 PM Arnout Vandecappelle <arnout@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@bootlin.com> wrote: > > >> > > >> On Fri, 30 Oct 2020 11:16:04 +0100 > > >> Bartosz Golaszewski <brgl@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
On 30/11/2020 21:31, Bartosz Golaszewski wrote: > 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? Include a copy of the latest uapi headers that you use directly in your source tree. At least, this is what libnl, iproute2, iw, hostapd and wpa_supplicant do.
diff --git a/package/libgpiod/Config.in b/package/libgpiod/Config.in index 63a7cb6e78..293eef6c89 100644 --- a/package/libgpiod/Config.in +++ b/package/libgpiod/Config.in @@ -5,7 +5,7 @@ config BR2_PACKAGE_LIBGPIOD This is a C library that abstracts the GPIO character device operations on linux. - https://github.com/brgl/libgpiod + https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ if BR2_PACKAGE_LIBGPIOD diff --git a/package/libgpiod/libgpiod.hash b/package/libgpiod/libgpiod.hash index f0009a7510..b05b4ae231 100644 --- a/package/libgpiod/libgpiod.hash +++ b/package/libgpiod/libgpiod.hash @@ -1,4 +1,5 @@ # From https://www.kernel.org/pub/software/libs/libgpiod/sha256sums.asc -sha256 21ae8fd1f8dafc2eb2ba50e652390cf533d21351419a7426255895cb52e21b1c libgpiod-1.4.1.tar.xz +sha256 f1cda2789e6a13a92aefc012a76e5a7cc57a1b402d66f71df8719ee314b67699 libgpiod-1.4.4.tar.xz +sha256 62908023d59e8cbb9137ddd14deec50ced862d8f9b8749f288d3dbe7967151ef libgpiod-1.6.tar.xz # Hash for license file sha256 ce64d5f7b49ea6d80fdb6d4cdee6839d1a94274f7493dc797c3b55b65ec8e9ed COPYING diff --git a/package/libgpiod/libgpiod.mk b/package/libgpiod/libgpiod.mk index 2474ab90a2..d5b38a6149 100644 --- a/package/libgpiod/libgpiod.mk +++ b/package/libgpiod/libgpiod.mk @@ -4,7 +4,12 @@ # ################################################################################ -LIBGPIOD_VERSION = 1.4.1 +# starting with 1.5 libgpiod depends on Headers >= 5.5 +ifeq ($(BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_5),y) +LIBGPIOD_VERSION = 1.6 +else +LIBGPIOD_VERSION = 1.4.4 +endif LIBGPIOD_SOURCE = libgpiod-$(LIBGPIOD_VERSION).tar.xz LIBGPIOD_SITE = https://www.kernel.org/pub/software/libs/libgpiod LIBGPIOD_LICENSE = LGPL-2.1+