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

[Andre McCurdy]

On Wed, Dec 11, 2019 at 5:13 PM Denys Dmytriyenko <denis at denix.org> wrote:
> On Wed, Dec 11, 2019 at 01:30:30PM -0500, Philip Balister wrote:
> > On 12/11/19 5:29 AM, 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:
> > >>>> -----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...
> >
> > From my point of view, the people that need CentOS 7 support need to
> > step up and do the work. The project can't allocate critical development
> > resources to support older distros.
>
> I agree with Philip here - we should not be spending already scarce
> engineering resources trying to shoehorn CentOS 7 support in.

We already spend scarce engineering resources on stuff like (just as
an example) gcc for the target, which is a far more "niche" use case
than CentOS 7 support.

You could also ask the question why do we have scarce engineering
resources? One factor is that OE is not user friendly and putting up
more barriers (ie stricter requirements on the host OS) isn't going to
help with that. Effort spent to increase the chances that OE "just
works" by automatically providing more of its dependencies and relying
less on the host may be a good investment in terms of alienating less
users, who may then persevere long enough to eventually become
contributors.

> I realize this is mostly about OE-Core, but on a related note, I very
> recently had to install a more modern gcc8 compiler on Ubuntu 16.04 on some
> of our build servers, as 16.04 was lacking recent C++ standards support
> in its default 5.4 compiler. The point is that we cannot keep on patching
> out every use of newer API to make it work with old OSes...
>
> --
> Denys
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture