[Buildroot] [PATCH 1/2] uclibc: add a missing function member to siginfo.h

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Dear Vicente Olivert Riera,

On Thu, 9 Jan 2014 09:46:13 +0000, Vicente Olivert Riera wrote:

> Yes, I understand what you mean, but what do you want to do? I mean, if 
> uClibc don't release new version, aren't you going to upgrade external 
> toolchains anymore?

Depends on which external toolchains we're talking about. In the
autobuilders, there are various external toolchains that are in use.
Amongst the uClibc based ones, we have:

 * Toolchains built using Buildroot itself. These are not very
   problematic, as I can rebuild them when a new version of Buildroot
   containing useful backported uClibc patches is released. Though it'd
   be great if I wasn't forced to rebuild these toolchains too often.

 * Toolchains built using Crosstool-NG. Those will *not* contain the
   backported uClibc patches that we have in Buildroot. There is a lot
   less uClibc patch backporting activity going on in Crosstool-NG, if
   any.

 * Toolchains coming from vendors, such as the Analog Devices
   toolchain. There's nothing we can do about them.

Therefore, having Buildroot packages relying on so many backported
uClibc patches is getting more and more problematic.

> I think we should fix this for the Buildroot toolchain, because is "our" 
> toolchain and is "our" problem. If external toolchains don't apply those 
> patches, then that will be their problem. They can upgrade the toolchain 
> packaging uClibc to a git version number, so no releases is needed. Of 
> course I understand that having a release is better because that means 
> that the state is consistent, it shouldn't fail, has been tested, etc., 
> but if that's not happening, again, is not our problem.

I think this is completely the wrong way of seeing things. Buildroot's
policy is that we should deviate as little as possible from upstream.
We don't have the man-power to maintain our own set of crazy patches on
top of this or that component. Whenever someone wanted to post patches
adding features to this or that component, we've always rejected them,
and encouraged the contributor to get them merged in the upstream
component instead.

I think it should be the same with uClibc. If some package doesn't work
with an uClibc release, then we should simply exclude this package
entirely from being built with any uClibc toolchain. And if people are
not happy with that, then they should either engage with the
upstream uClibc to ensure that they do releases at reasonable
intervals, or they should realize that uClibc is a near-dead project,
and therefore that switching to another C library probably makes sense.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com