bump libnl to 3.2.21 before release
Hi,
The libnl library versions 3.2.18 and 3.2.19 have an unnecessary incompatibility problem that has been removed in the later versions. This problem affected me and went away when I went to 3.2.21.
I suggest we bump the libnl package to 3.2.21, before the release, to avoid that incompatibility mess.
From libnl website:
Important: 3.2.10 reverted an an uneeded SONAME bump that was done due to an ABI/API breakage in an unused API. After severe discussion, it was decided to undo the SONAME bump to make life easier for distribution maintainers by removing the unused APIs from the public header files and by providing compat header files that mistakenly included them.
If you linked against 3.2.18 or 3.2.19 your binary will not be compatible with >= 3.2.20. You will have to relink your binary. We are sorry for any inconvenience this may cause.
Note: The API/ABI that is exported as of 3.2.21 is considered 100% stable. No more exceptions that cause confusion and breakage. I will no longer merge patches that break API/ABI even though the API seems unused at this point. Things have been broken too many times.
Regards,
Dimitris
Quoted 8 lines · Dimitrios Siganos
If you linked against 3.2.18 or 3.2.19 your binary will not be compatible with >= 3.2.20. You will have to relink your binary. We are sorry for any inconvenience this may cause.
Note: The API/ABI that is exported as of 3.2.21 is considered 100% stable. No more exceptions that cause confusion and breakage. I will no longer merge patches that break API/ABI even though the API seems unused at this point. Things have been broken too many times.
The keyword here is "binary".
Breaking ABI isn't important in the buildroot context of packages since you're building from source thus you don't care about ABI. It's the same boat like when we moved the openssl package from 0.9.8* to 1.0.*
Is there any explicit problem 3.2.18 causes that affects you? Regards.
Quoted 10 lines · Gustavo Zacarias
Quoted 8 lines · Dimitrios Siganos
If you linked against 3.2.18 or 3.2.19 your binary will not be compatible with >= 3.2.20. You will have to relink your binary. We are sorry for any inconvenience this may cause.
Note: The API/ABI that is exported as of 3.2.21 is considered 100% stable. No more exceptions that cause confusion and breakage. I will no longer merge patches that break API/ABI even though the API seems unused at this point. Things have been broken too many times.
Quoted 8 lines
The keyword here is "binary".
Breaking ABI isn't important in the buildroot context of packages since you're building from source thus you don't care about ABI. It's the same boat like when we moved the openssl package from 0.9.8* to 1.0.*
Is there any explicit problem 3.2.18 causes that affects you? Regards.
There is no problem that I can't work around but it is an inconvenience that can be avoided.
How am I affected? We do binary releases of our software applications and 3.2.18 doesn't work for us and we'd have to release a special version for that or create a patch for buildroot.
The important thing to note here is that version 3.2.18 broke backwards compatibility and version 3.2.20 restored it. For example, v3.2.16 is compatible with 3.2.21 but 3.2.18 isn't compatible with either of them.
If there is no specific reason to stay at 3.2.18 then why not go to 3.2.21 and spare some buildroot users (the ones that operate in mixed open/closed source) from that unnecessary libnl hassle?
Regards,
Dimitris
Quoted 6 lines · Dimitrios Siganos
There is no problem that I can't work around but it is an inconvenience that can be avoided.
How am I affected? We do binary releases of our software applications and 3.2.18 doesn't work for us and we'd have to release a special version for that or create a patch for buildroot.
Binary releases as in a sepparate/propietary app that's only shipped as a binary? (not built with buildroot and/or not able to share the source). I'm not asking because of any licensing crazyiness, it's perfectly valid, just want to understand the scenario.
Quoted 7 lines
The important thing to note here is that version 3.2.18 broke backwards compatibility and version 3.2.20 restored it. For example, v3.2.16 is compatible with 3.2.21 but 3.2.18 isn't compatible with either of them.
If there is no specific reason to stay at 3.2.18 then why not go to 3.2.21 and spare some buildroot users (the ones that operate in mixed open/closed source) from that unnecessary libnl hassle?
Well the binary compatibility isn't an issue for typical buildroot scenarios, that's why i'm asking what i asked.
The changelog entry is a typical linux distribution issue where you just upgrade individual components when necessary.
That's usually not what buildroot is about, you're building a root filesystem (in simplified terms) so your upgrade path is usually a complete image upgrade, call it firmware, flash or disk image. Hence ABI compatibility doesn't matter.
Understand i'm hesitant to bump libnl this close to the release unless there's a really pressing issue - libnl bumps usually break packages subtly and this requires testing.
And it also breaks every other release with varying linux headers when new features are introduced (like CAN support).
Regards.
Quoted 5 lines · Gustavo Zacarias
Quoted 3 lines · Dimitrios Siganos
There is no problem that I can't work around but it is an inconvenience that can be avoided.
Quoted 8 lines
Quoted 3 lines
How am I affected? We do binary releases of our software applications and 3.2.18 doesn't work for us and we'd have to release a special version for that or create a patch for buildroot.
Binary releases as in a sepparate/propietary app that's only shipped as a binary? (not built with buildroot and/or not able to share the source). I'm not asking because of any licensing crazyiness, it's perfectly valid, just want to understand the scenario.
Yes, we ship our app without sources and only in binary form. However, we also sell linux hardware modules with a ready to go buildroot environment so that customers can build their own apps too. Obviously, we'd liek our customers to integrate our software into buildroot with as little hassle as possible and API breakages make our more difficult. This ABI in unnecessary, so that's why I asked you to consider bumping the version.
Quoted 8 lines
Quoted 7 lines
The important thing to note here is that version 3.2.18 broke backwards compatibility and version 3.2.20 restored it. For example, v3.2.16 is compatible with 3.2.21 but 3.2.18 isn't compatible with either of them.
If there is no specific reason to stay at 3.2.18 then why not go to 3.2.21 and spare some buildroot users (the ones that operate in mixed open/closed source) from that unnecessary libnl hassle?
Quoted 13 lines
Well the binary compatibility isn't an issue for typical buildroot scenarios, that's why i'm asking what i asked.
The changelog entry is a typical linux distribution issue where you just upgrade individual components when necessary.
That's usually not what buildroot is about, you're building a root filesystem (in simplified terms) so your upgrade path is usually a complete image upgrade, call it firmware, flash or disk image. Hence ABI compatibility doesn't matter.
Understand i'm hesitant to bump libnl this close to the release unless there's a really pressing issue - libnl bumps usually break packages subtly and this requires testing.
And it also breaks every other release with varying linux headers when new features are introduced (like CAN support).
OK, I just thought I'll ask. Obviously it seems to work for me but I guess you are worried about the packages that I am not using and not testing, which is understandable. I can work around this by applying a patch to buildroot to avoid this ABI breakage. Thanks for listening.
Regards,
Dimitris