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.
> 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.
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
