[Openembedded-architecture] Yocto support for Centos-7 (RHEL-7): drop in early 2020?

[Richard Purdie]

On Wed, 2019-12-11 at 11:18 +0100, Andreas Müller wrote:
> On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
> Openembedded-architecture
> <openembedded-architecture at lists.openembedded.org> wrote:
> > > -----Original Message-----
> > > From: openembedded-architecture-bounces at lists.openembedded.org
> > > <openembedded-architecture-bounces at lists.openembedded.org> On
> > > Behalf Of
> > > Khem Raj
> > > Sent: 10 December 2019 20:35
> > > To: Randy MacLeod <randy.macleod at windriver.com>
> > > Cc: openembedded-architecture <openembedded-
> > > architecture at lists.openembedded.org>
> > > Subject: Re: [Openembedded-architecture] Yocto support for
> > > Centos-7 (RHEL-7):
> > > drop in early 2020?
> > > 
> > > On Tue, Dec 10, 2019 at 9:23 AM Randy MacLeod
> > > <randy.macleod at windriver.com> wrote:
> > > > 
> > > > In the YP technical meeting today, Richard suggested that we
> > > > stop
> > > > support for CentOS-7. Is there any objection to doing so before
> > > > 3.1-M2?
> > > > 
> > > > CentOS-7 is just too old and there is significant work to
> > > > support it.
> > > 
> > > I am in support of it, but then I also fear that many corporate
> > > policies might still
> > > be using it until 2024 when security updates end so perhaps would
> > > like to hear
> > > centos7 users here. if no one speaks up then we can safely retire
> > > it before 3.1
> > > 
> > 
> > While I see what the motivation to remove CentOS-7 is, dropping it
> > will probably create issues for people. CentOS 8 was released not
> > so long ago. In our case we have older products (among which Yocto
> > based ones) which do not necessarily work on CentOS 8. CentOS 8 is
> > relatively recent, so we have not had time to test how old products
> > work on it.
> > 
> > Isn't it possible to require things like devtoolset-8 (gcc 8.3,
> > binutils-2.30) on CentOS 7 to keep it going?
> > 
> > In our case we are using devtoolset-8 with Yocto thud on CentOS 7
> > with success, as some layers require a recent host gcc to build.
> > 
> How about extending uninative with more gcc bits?

uninative isn't the right place. What we'd need is a nativesdk-gcc
recipe and then to add nativesdk-gcc to buildtools-tarball.

We could then add some mechanism to auto-install buildtools tarball up
front on systems that need it, in a similar way to what uninative does.

Definitely possible and would solve certain problems, we'd just need
someone to implement it...

Cheers,

Richard