Re: PREFERRED_PROVIDER in image recipes

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2013-01-30 at 00:37 -0500, Bruce Ashfield wrote:
> On 13-01-28 11:16 AM, Daniel Kenji Morgan wrote:
> > Sorry to bring up an old post, but I haven't managed to find information in the mail archives and bugzilla on how the issue stands as of today.
> >
> > The post I am referring to is as follows:
> > https://lists.yoctoproject.org/pipermail/yocto/2011-December/005951.html
> >
> > I have two separate recipes for the same kernel version.
> > One with a kernel configuration with various options enabled to assist debugging.
> > The other with said options disabled.
> >
> > Ideally, I would like to be able to set PREFERRED_PROVIDER to the kernel recipes in custom image recipes for the same machine.
> > This is something that is being discussed in the referred post above.
> > Does anyone know if such functionality is being pursued in a future release of Poky?
> 
> I haven't heard of anything myself, local.conf, distro configs or
> separate machines are how this is still currently being done.
> 
> We have quite a bit of flexibility in the way that kernel configs
> can be stacked and used since the thread that you noticed, so there
> are options in that area to pursue as well. There's been planning
> around image creation and construction lately, that could also end
> up helping a use case such as this down the road.
> 
> As to whether or not work is planned in the areas of images and
> preferred providers, Richard would know.

PREFERRED_PROVIDER is fundamentally a top level configuration level
option. It *cannot* be specified at the image level, its just not the
way bitbake and the whole system works.

Think about this from the packages perspective - what would we do with
two sets of kernel modules which may or may not overwrite each other?
That is a packaging limitation, not a bitbake one but its one of several
problems we'd have to overcome to address this.

So no, there are no plans to try and change this functionality in future
releases, its simply not something we have a good plan even for
implementing at this point. If someone comes up with a well thought out
plan, great but there isn't one right now and I don't even have ideas
about how we could solve all the problems.

Cheers,

Richard