[Buildroot] bump libnl to 3.2.21 before release

[Buildroot] bump libnl to 3.2.21 before release

[Dimitrios Siganos]

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

[Buildroot] bump libnl to 3.2.21 before release

[Gustavo Zacarias]

On 02/17/2013 03:49 PM, Dimitrios Siganos wrote:
> 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.

[Buildroot] bump libnl to 3.2.21 before release

[Dimitrios Siganos]

On 17/02/13 18:55, Gustavo Zacarias wrote:
> On 02/17/2013 03:49 PM, Dimitrios Siganos wrote:
>> 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.
> 

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

[Buildroot] bump libnl to 3.2.21 before release

[Gustavo Zacarias]

On 02/17/2013 05:57 PM, Dimitrios Siganos wrote:

> 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.

> 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.

[Buildroot] bump libnl to 3.2.21 before release

[Dimitrios Siganos]

On 17/02/13 21:06, Gustavo Zacarias wrote:
> On 02/17/2013 05:57 PM, Dimitrios Siganos wrote:
> 
>> 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.

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.


>> 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).

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