[OE-core] [PATCH V3] u-boot-fw-utils: Add support for libubootenv

[Stefano Babic]

Hi Richard,

On 03/01/20 12:18, Richard Purdie wrote:
> On Fri, 2020-01-03 at 12:05 +0100, Stefano Babic wrote:
>> On 03/01/20 11:40, Richard Purdie wrote:
>>> On Fri, 2020-01-03 at 11:15 +0100, Stefano Babic wrote:
>>>> libubootenv is a replacement for u-boot-fw-utils. It is
>>>> hardware-independent and provides fw_printenv and fw_setenv tools
>>>> that
>>>> are full compatible with the ones provided by U-Boot. A library
>>>> is
>>>> provided to access the environment from an own application.
>>>> License is LGPL-2.1 and this allow to link the library to
>>>> proprietary
>>>> code. The user of the tools should install the configuration file
>>>> "fw_env.config", as he is already used to with u-boot-fw-utils.
>>>> The
>>>> configuration file is compatible with u-boot-fw-utils.
>>>>
>>>> +PROVIDES += "u-boot-fw-utils"
>>>> +RPROVIDES_${PN} += "u-boot-fw-utils"
>>>
>>> What is the ultimate intention/end goal here? Does this replace u-
>>> boot-
>>> fw-utils? 
>>
>> Frankly speaking, yes. The topic was discussed more as a year ago on
>> U-Boot's ML, and libubootenv is the result of this (long) discussion:
>> 	
>> http://u-boot.10912.n7.nabble.com/SWUpdate-U-Boot-environment-library-dependency-tt340530.html#none
>>
>> One of the major goal is to solve the fragile connection between u-
>> boot U-Boot's ML, and libubootenv is the result of this (long)
>> discussion:
> 
>> has always been a pitfall, specially when projects sets a custom BSP
>> layer replacing U-Boot with a custom recipe, and then people wonder
>> why board is bricked. Licensing (LGPL2.1 instead of GPLv2) is another
>> major goal, too, that libubootenv solves.
> 
> Thanks, this was a leading question as I suspected this might be the
> case. I think there will be less push back from people about a new
> recipe if it is clear its a replacement,

Ok

> it has the backing of upstream
> and it has compatibility, all of which seems to be the case.

Yes, it is.

> 
> People on this list won't have seen the other discussion so this is
> important context to add for them. Its worth putting in the commit
> message too since others may look at the commit later to find out what
> they need to do to migrate.

Of course, I will add it to commit message.

> 
>>> Should we remove the other recipe?
>>
>> libubootenv is thought to be full compatible with u-boot-fw-utils,
>> and it was already pushed in many projects. So yes, my proposal and
>> final goal is then to drop u-boot-fw-utils.
>>
>> Anyway, I do not know if you prefer to have a "transition" time with
>> both recipes or it is fine for you to drop soon u-boot-fw-utils.
> 
> My personal perspective in this context is we should replace. The
> PROVIDES you add means the original recipe is effectively masked out
> anyway.
> 
> Your patch needs to update the maintainers.inc file to reflect the new
> recipe name (it would fail in testing now as it doesn't add a
> maintainer for the new recipe).

Thanks, I'll do in V4.

Regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================