[OE-core] [PATCH] u-boot: Add RPROVIDES bootloader

[Otavio Salvador]

On Mon, Dec 5, 2016 at 5:56 PM, Paul Eggleton
<paul.eggleton at linux.intel.com> wrote:
> On Mon, 05 Dec 2016 17:45:40 Otavio Salvador wrote:
>> On Mon, Dec 5, 2016 at 5:31 PM, Paul Eggleton
>>
>> <paul.eggleton at linux.intel.com> wrote:
>> > On Fri, 02 Dec 2016 11:59:52 Fabio Berton wrote:
>> >> This change allow to install u-boot in /boot partition using
>> >> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
>> >>
>> >> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
>> >>
>> >> This is usefull when system has only one partition and u-boot,
>> >> kernel and device tree need to be installed in /boot.
>> >
>> > If the intention is that other packages also have "bootloader" in
>> > RPROVIDES, I thought that these kinds of "virtual provides" weren't
>> > supported well by all of the package managers. (We might get away with it
>> > here since they probably will all be in their own separate
>> > machine-specific feeds, though).
>>
>> The point in having the bootloader is because different bootloaders
>> may provide the functionality for the board. This is especially keen
>> for commercial distributions where a U-Boot fork may include fixes and
>> this should be used on top of the BSP default and without many changes
>> on the layer.
>>
>> As you pointed out, the U-Boot usually has a single provider as it is
>> a MACHINE_ARCH package. I think it is a safe addition, isn't it?
>
> If we can guarantee that there will only be one runtime provider of
> "bootloader", then I would assume so, yes.
>
> One question - at OEDEM (based on the minutes, I wasn't there) the
> proliferation of u-boot recipes across BSPs was discussed and there was at
> least a desire to try to move to a single recipe where practically possible.
> Do you have any opinions on that? I bring it up because if there was only
> "u-boot" presumably we wouldn't need the "bootloader" RPROVIDES at all.

I agree and I think this should be a continuous goal for the entire
project and Yocto Project members, however, this is unlikely to happen
as internal BSPs and custom boards will always keep forked versions
around.

Even though having a single recipe is not going to happen, reducing
the fragmentation is very possible and desirable. We did some of work
on meta-freescale on this direction making many board to use
u-boot-fslc as provider. Some vendors moved to it while others keep
using their forks.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750