[Arm-dev] a plague farm ?

Fri May 1 12:14:02 UTC 2015
Jacco Ligthart <jacco at redsleeve.org>

On 05/01/2015 01:25 PM, Gordan Bobic wrote:
> On 2015-05-01 09:42, Karanbir Singh wrote:
>> On 04/29/2015 06:46 PM, Jacco Ligthart wrote:
>>> For RedSleeve7 I patched the stock CentOS/RH kernel until it builded.
>>> All packages have been build against this kernel-headers.
>>
>> but if you have patched it out - and assume that the kernel only gets
>> management / support / maintainence, is there any use in doing that ?
>> isnt it safer overall to communicate clearly that a newer, self managed
>> kernel was used ? What you have there certainly does not seem in a state
>> where you could asset its the distro kernel. Or is it ?
>
> I think we need to make a clear separation here between the kernel
> and userspace, because Linus' policy is to never break userspace
> with kernel ABI changes.
>
> This is purely to give userspace programs the kernel headers they
> expect to build against, and more importantly, to give mock a
> usable binary rpm to install to satisfy the dependencies the
> userspace package source rpm requires.
>
> What kernel you end up using to run the system is irrelevant.
> Unfortunately, in the ARM world you often have to use whatever
> kernel has patches, or even just binaries available that work
> on the machine. If you can stick with SoC/board combinations
> that have upstream mainline support, that's awesome, but that
> is still very much not always the case. But that doesn't
> really make any difference to the userspace (e.g. in RS6
> the recommendation is to use whatever kernel your device
> ships with and use that with the EL6 userspace, for purely
> pragmatic reasons.
>
Like Gordan says, it's mostly for pragmatic reasons.
One of the issues I found was that I was not able to build the raspberry
pi kernel (3.18.something) with the CentOS 7.0 gcc. The kernel
complained that that gcc version was known to break kernel builds. (the
7.1 gcc version is just that much newer that it now works)

Similarly, I expect some other packages to FTBFS if presented with newer
kernel-headers.

Anyhow, I was not trying to convince you that this is the way you should
do it. It's just what I've done. And, at the same time, if you also want
to go down this route, that I have patches available, to kick-start such
an endeavor.

Jacco