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

Andre McCurdy armccurdy at gmail.com
Thu Dec 12 18:33:16 UTC 2019


On Wed, Dec 11, 2019 at 9:55 PM Adrian Bunk <bunk at stusta.de> wrote:
> On Wed, Dec 11, 2019 at 08:48:04PM -0800, Andre McCurdy wrote:
> > On Wed, Dec 11, 2019 at 7:38 PM Adrian Bunk <bunk at stusta.de> wrote:
> > >
> > > There is no need to question whether niche features like gcc or GNOME
> > > for the target is a useful way of spending resources since the work is
> > > done by the people interested in the feature.
> >
> > Yes, that's probably expected. Developers work on stuff which
> > interests them. That's precisely why there's a danger that effort and
> > resources don't always get spent on the work which would benefit the
> > widest range of users.
>
> This is not a danger, this is how open source projects work.

Yes, it's how open source projects work. It's also a model where
there's a risk that the best interests of the wider user base don't
get much consideration. There's no conflict between those two
statements.

> Yocto is not a company where all developers are paid resources that can
> be told what to spend their time on.
>
> Developers spend effort on what is useful for their local paid work,
> or what is fun to do as a hobby.
>
> >...
> > > In some cases this even creates new bugs for everyone else,
> > > like the breakage caused by an incorrect CentOS 7 workaround in nettle
> > > that needed a last-minute fixup before the release of Yocto 2.7.
> >
> > That was an embarrassing mistake, which you've brought up before.
>
> Not exactly embarrassing, the problem is obvious only in hindsight.
>
> > It happens sometimes. Dropping support for CentOS 7 or musl isn't going
> > to stop embarrassing mistakes happening again.
> >...
>
> It avoids bugs being introduced by workarounds.
>
> Trying to build and run 2020 software on a 2013 distribution is
> problematic, and will generate more and more problems noone else
> has seen or is interested in fixing.

In general yes, but build environments are somewhat of a special in
that one of their key functions is to isolate the code being built
from any specific details of the host. OE already does a very good job
of doing that (by building -native versions of many of the tools
traditionally provided by the host in legacy build environment, etc)
but if there are ways to improve that isolation even further then I
don't think we should dismiss efforts to work on them just because key
developers are happy with the level of isolation we have already.

> Bumping the baseline by 3 years to Ubuntu 16.04 would make both existing
> and future OE-specific workarounds for ancient hosts unnecessary.
>
> cu
> Adrian


More information about the Openembedded-architecture mailing list