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

[Richard Purdie]

On Wed, 2019-12-11 at 14:13 +0200, Adrian Bunk wrote:
> On Wed, Dec 11, 2019 at 10:29:27AM +0000, Richard Purdie wrote:
> > 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:
> > > > 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...
> 
> What you describe sounds like a manual and painful way to create
> some kind of container - once you have toolchain/chrpath/tar/... of
> the host replaced there is not much left that is actually used from
> the host.
> 
> The simple and sane solution would be to provide or require a
> container with a supported distribution instead.

We already have the technology for most of it and its tried and tested.

Creating containers, whilst easier than it ever used to be, does
usually require elevated permissions and can cause problems with things
like qemu acceleration and networking. If you've already dealt with
that, fine but some setups wouldn't have.

So for some use cases containers are simpler, for some they are harder,
and this would help.

Thinking about it, it may well be the easiest way of supporting LTS on
older distros on the autobuilder workers too. I know Tim is looking at
the container angle there but this one is much easier to do from a
permissions standpoint.

Yes, its old fashioned, totally agree on that. 

Cheers,

Richard