[OE-core] [PATCH 3/3] sanity: Add check for tar older than 1.28

[Mark Hatle]

On 11/21/19 12:09 PM, Richard Purdie wrote:
> On Thu, 2019-11-21 at 19:09 +0200, Adrian Bunk wrote:
>> On Thu, Nov 21, 2019 at 04:54:12PM +0000, Richard Purdie wrote:
>>> On Thu, 2019-11-21 at 17:50 +0200, Adrian Bunk wrote:
>>>> On Thu, Nov 21, 2019 at 03:02:07PM +0000, Richard Purdie wrote:
>>>>> Older versions break opkg-build when reproducible builds are
>>>>> enabled.
>>>>> Rather than trying to be selective based on which features are
>>>>> enabled,
>>>>> lets just make this a minimum version.
>>>>> ...
>>>>> +    if LooseVersion(version) < LooseVersion("1.28"):
>>>>> +        return "Your version of tar is older than 1.28 and
>>>>> does
>>>>> not have the support needed to enable reproducible builds.
>>>>> Please
>>>>> install a newer version of tar.\n"
>>>>> ...
>>>>
>>>> How does "Please install a newer version of tar" work in practice
>>>> on a supported host distribution like CentOS 7 ?
>>>>
>>>> As user I would expect such things to just work when using
>>>> a distribution that is documented as supported.
>>>
>>> We're going to have to solve this issue on our autobuilder. Centos7
>>> already causes problems and there is documetation in the manual
>>> about
>>> it:
>>>
>>> https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#centos-packages
>>>
>>> (and the need to use EPEL)
>>>
>>> Unfortunately a newer tar isn't in EPEL.
>>
>> EPEL does not contain more recent versions of packages already
>> in RHEL/CentOS.
> 
> Sorry, I had thought Centos7 had python3 already and we needed EPEL to
> obtain python 3.6.
> 
>>
>>> I don't have a solution yet, I do know that silently creating empty
>>> packages is much worst than telling a user something won't work
>>> though.
>>>
>>> Any suggestions on how we fix it?
>>
>> My preferred solution would be to replace CentOS 7 with CentOS 8
>> as supported distribution, which would also allow to drop hacks
>> for two major releases of gcc in various places.
> 
> We are working towards that, equally the older version support is
> useful to a significant portion of our userbase so its a balancing act.

RHEL 7 is still heavily used.  But if we can provide a buildtools-tarball that
includes a new enough tar, that should be able to workaround the issue.

>> If all other supported distribution already ship 1.28 this would
>> solve your problem.
> 
> I believe that is now the case, yes.
> 
>>> (We could make opkg-utils-native depend on tar-native but for most
>>> people that isn't necessary so it seems a shame).
>>
>> Building tar-native is not something that would strike me as 
>> problematic.
> 
> Its an extra build dependency and extra build time, just complicates
> things. "tar-native" is in ASSUME_PROVIDED and gives bootstrap issues
> although we have the "tar-replacement-native" mechanism to account for
> this already. So possible but not entirely straightforward.

Requiring a newer version, and suggesting to the user to use a
buildtools-tarball (SDK) I think is a reasonable compromise.

> Cheers,
> 
> Richard
>