Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: richard.purdie@linuxfoundation.org
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 2/2] uninative: Switch from bz2 to xz
Date: Thu, 30 May 2019 17:25:18 +0300	[thread overview]
Message-ID: <20190530142518.GC318@localhost> (raw)
In-Reply-To: <e7536283bb0d7d255826585a3222aedd0d7950ad.camel@linuxfoundation.org>

On Thu, May 30, 2019 at 03:06:56PM +0100, richard.purdie@linuxfoundation.org wrote:
> On Thu, 2019-05-30 at 16:59 +0300, Adrian Bunk wrote:
> > There are also some other related topics that might be considered
> > on how this should develop long-term:
> > 
> > 1. How important is it to support host distributions that are not 
> > listed as supported? Not limited to uninative it can be painful
> > adding support for new distributions to stable branches.
> 
> The distros we do support were chosen to give a decent cross section of
> the Linux ecosystem. Whilst not full coverage, the delta between those
> and other systems should be relatively minimal as we have both older
> and modern in there.

I agree that it usually works on the range between the oldest and the 
newest supported host distribution.

But adding support for more recent host distributions to stable 
branches could end up being any amount of troubles if you are
unlucky.

> > 2. Does using uninative by default bring enough benefits to
> > outweight the problems with new host distributions, or should it
> > become non-default in master?
> 
> We test it heavily on the autobuilder and also benefit from it
> massively there so in my view its a significant win for us alone. We
> chose to share it with the ecosystem. You're not forced to use it.
> 
> > The sum of the two points above is especially problematic:
> > "re-use of native shared state artifacts across different host 
> > distributions" is a more exotic feature, and effectively supporting
> > this for unsupported host distributions is the problem here.
> 
> Which distros are you seeing a problem with and what kinds of problems?
> I'd hoped/believed the problems should be relatively minor unless
> they're really old.
>...

The problem is that uninative is expected to break 3 times per year, 
with every new release of gcc or glibc.

Are the problems people regularly see on bleeding-edge distributions
really offset by the benefits of having it enabled by default?

> Cheers,
> 
> Richard

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed



  reply	other threads:[~2019-05-30 14:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 18:43 [PATCH 1/2] yocto-uninative: Update to 2.5 release Richard Purdie
2019-05-29 18:43 ` [PATCH 2/2] uninative: Switch from bz2 to xz Richard Purdie
2019-05-29 19:21   ` akuster808
2019-05-29 19:26     ` richard.purdie
2019-05-29 20:39       ` akuster808
2019-05-29 20:50         ` richard.purdie
2019-05-29 21:25           ` Tom Rini
2019-05-29 21:29             ` richard.purdie
2019-05-29 22:17               ` Adrian Bunk
2019-05-29 22:29                 ` Tom Rini
2019-05-29 23:02                   ` Adrian Bunk
2019-05-30  8:13                     ` richard.purdie
2019-05-30 13:32                       ` akuster808
2019-05-30 13:55                         ` richard.purdie
2019-05-30 15:57                           ` Tom Rini
2019-05-31 13:44                             ` richard.purdie
2019-05-30 13:59                       ` Adrian Bunk
2019-05-30 14:06                         ` richard.purdie
2019-05-30 14:25                           ` Adrian Bunk [this message]
2019-05-30 14:15                         ` akuster808
2019-05-30  2:54                   ` Tim Orling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190530142518.GC318@localhost \
    --to=bunk@stusta.de \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox