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 > >> <[email protected]> wrote: > >>>> -----Original Message----- > >>>> From: [email protected] > >>>> <[email protected]> On > >>>> Behalf Of > >>>> Khem Raj > >>>> Sent: 10 December 2019 20:35 > >>>> To: Randy MacLeod <[email protected]> > >>>> Cc: openembedded-architecture <openembedded- > >>>> [email protected]> > >>>> 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 > >>>> <[email protected]> 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. 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 [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
