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

[Richard Purdie]

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, it has the backing of upstream
and it has compatibility, all of which seems to be the case.

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.

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

Cheers,

Richard