[OE-core] [PATCH 0/3] Dynamic common utilities

[Otavio Salvador]

On Fri, Sep 18, 2015 at 12:44 PM, Mark Hatle <mark.hatle at 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