On Mon, 05 Dec 2016 17:45:40 Otavio Salvador wrote: > On Mon, Dec 5, 2016 at 5:31 PM, Paul Eggleton > > <paul.eggle...@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. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
