[OE-core] PRServer's problem

Paul Eggleton paul.eggleton at linux.intel.com
Thu May 19 11:10:31 UTC 2016


On Thu, 19 May 2016 11:37:03 Joshua G Lock wrote:
> On Thu, 2016-05-19 at 18:12 +0800, Robert Yang wrote:
> > On 05/19/2016 05:45 PM, Richard Purdie wrote:
> > > Users are free to set their own policies, the system was designed
> > > to do
> > > that. If WindRiver wants to have a much more permissive policy, I'm
> > > more than happy for them to do so.
> > 
> > Thanks, frankly speaking, not only WindRiver wants this. After cloud
> > computing and virtualization gets hot, more and more users want to
> > customize their own images (for saving disk space, memory and
> > security
> > reason), oe/yocto is very good at customizing images, so more and
> > more people try to use it to build their own distros, where live
> > upgrades becomes very important.
> 
> The desire for this is well understood, which is why work began on the
> packagefeed-stability class. 
> 
> Paul's initial effort is solid and works for simple cases, I had a
> brief look at it and tried to identify some of the issues and wrote
> some minor patches (for things like versioned depends and copying all
> packages for a recipe as soon as a difference is found) but
> unfortunately I haven't had time to finish the work.
> 
> The main piece we're missing is to define tests (in the test suite) to
> validate the class works as expected with each of the package backends
> and through those tests identify areas where it doesn't work (and of
> course fix them).
> 
> Regards,
> 
> Joshua
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=8318

Also as I believe I mentioned in my RFC (IIRC) whilst it does basically work I 
was not exactly impressed by the build-compare tool's error handling, there 
were errors produced during some of my runs and yet the script itself 
succeeded, which gives me less confidence about the results. I haven't looked 
to see if there's a new version upstream that is improved in this regard 
though, and even if there isn't we do have the option of patching it ourselves 
(and sending the fix upstream, naturally).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the Openembedded-core mailing list