On Fri, Sep 18, 2015 at 12:44 PM, Mark Hatle <mark.ha...@windriver.com> wrote: > On 9/18/15 4:35 AM, Jack Mitchell wrote: >> On 17/09/15 17:20, Alejandro Joya wrote: >>> It provide a virtual reference for the common utilities. >>> it replace of the lock to busybox, it will be simple exchange between other >>> common utilities like gnu core utils or toybox among others. >>> >>> In order to enable its required to fill at the distro conf or local.conf >>> >>> VIRTUAL-RUNTIME_login_manager ?= "busybox" >>> PREFERRED_PROVIDER_virtual/anybox ?= "busybox" >>> PREFERRED_RPROVIDER_virtual/anybox ?= "busybox" >>> VIRTUAL-RUNTIME_anybox ?= "busybox" >>> VIRTUAL-RUNTIME_anybox-hwclock ?= "busybox-hwclock" >>> >>> The following changes since commit f0189829498e30231d826c9f55aad73e622d076e: >>> >>> qemu: Update to upstream patches (2015-09-14 11:22:02 +0100) >>> >>> are available in the git repository at: >>> >>> git://github.com/Ajoyacr/openembedded-core anybox >>> https://github.com/Ajoyacr/openembedded-core/tree/anybox >>> >>> Alejandro Joya (3): >>> core-mage-minimal-initramfs: overwrite hardcoded dependency to virtual >>> reference >>> initramfs-framework: overwrite hardcoded dependency to virtual >>> reference >>> packagegroup-core-boot: overwrite hardcoded dependency to virtual >>> reference >>> >>> meta/recipes-core/images/core-image-minimal-initramfs.bb | 2 +- >>> meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 2 +- >>> meta/recipes-core/packagegroups/packagegroup-core-boot.bb | 6 +++--- >>> 3 files changed, 5 insertions(+), 5 deletions(-) >>> >> >> is 'anybox' a good name for the virtual provider? What happens if we have a >> new >> suite of core utility replacements without box in the name, I assume it will >> be >> a nightmare to retroactivly change the name so we should probably come up >> with a >> more generic one now. virtual/core-utils, virtual/base-utils? > > Personally I like this better -- however, I think we're "too late" in the > current development cycle to do it.. but for the next cycle, we should > certainly consider going through the system and doing this instead. > > (It will definitely make it easier in the future to get rid of a "box" based > system if desired.)
Agreed; this should be postponed for 2.1 and than we come up with a proper virtual name when revisiting this patchset. -- 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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core