Re: [PATCH 0/3] Dynamic common utilities

[Mark Hatle <mark.hatle@windriver.com>]

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.)

--Mark

> Cheers,
> Jack.
>