[OE-core] [PATCH 2/2] uninative: Switch from bz2 to xz

akuster808 akuster808 at gmail.com
Thu May 30 14:15:49 UTC 2019



On 5/30/19 6:59 AM, Adrian Bunk wrote:
> On Thu, May 30, 2019 at 09:13:02AM +0100, richard.purdie at linuxfoundation.org wrote:
>> ...
>> I'm torn, partly as if we stick with bz2, we effectively do that
>> perpetually and given the size difference, we should switch.
>>
>> Tim mentions we could fix the crops container and I'm tempted to switch
>> given we're so close with the current patchset...
>>
>> We can add xz to HOSTTOOLS in master and that makes sense for a number
>> of other reasons but gets tricky as we can't add it to ASSUME_PROVIDED
>> as easily due to the libs it provides. I think we only need to worry
>> about this on master though.
> There are also some other related topics that might be considered
> on how this should develop long-term:
>
> 1. How important is it to support host distributions that are not 
> listed as supported? Not limited to uninative it can be painful
> adding support for new distributions to stable branches.

When new hosts are added to the AB and a stable branch builds and all
tests pass on that host, we have updated the docs to reflect such an
addition.
its not a fun exercise and gets harder the older the stable branch is.

It is also noted in the Stable branch maintenance story on wiki and has
been SOP for years.

- armin
>
> 2. Does using uninative by default bring enough benefits to outweight 
> the problems with new host distributions, or should it become 
> non-default in master?
>
> The sum of the two points above is especially problematic:
> "re-use of native shared state artifacts across different host 
> distributions" is a more exotic feature, and effectively supporting
> this for unsupported host distributions is the problem here.
>
> 3. uninative is so fragile because it tries to fix the C library
> only. A lot of problems with host distributions (not limited to
> uninative) would go away if one host distribution would be picked
> and provided as container for people who are using other distributions.
>
>> Cheers,
>>
>> Richard
> cu
> Adrian
>



More information about the Openembedded-core mailing list