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

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

[Stefano Babic]

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.

Signed-off-by: Stefano Babic <sbabic@denx.de>
---
Changes since V2:
	- drop .inc file (R. Burton)
Changes since V1:
	- drop PACKAGE_ARCH (M. Jansa)

 meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100644 meta/recipes-bsp/u-boot/libubootenv_0.2.bb

diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
new file mode 100644
index 0000000000..23230d132e
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
@@ -0,0 +1,26 @@
+SUMMARY = "U-Boot libraries and tools to access environment"
+DEPENDS += "mtd-utils"
+
+DESCRIPTION = "This package contains tools and libraries to read \
+and modify U-Boot environment. \
+It provides a hardware-independent replacement for fw_printenv/setenv utilities \
+provided by U-Boot"
+
+HOMEPAGE = "https://github.com/sbabic/libubootenv"
+LICENSE = "LGPL-2.1"
+LIC_FILES_CHKSUM = "file://Licenses/lgpl-2.1.txt;md5=4fbd65380cdd255951079008b364516c"
+SECTION = "libs"
+
+SRC_URI = "git://github.com/sbabic/libubootenv;protocol=https"
+SRCREV = "bf6ff631c0e38cede67268ceb8bf1383b5f8848e"
+
+S = "${WORKDIR}/git"
+
+inherit cmake
+
+EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
+
+PROVIDES += "u-boot-fw-utils"
+RPROVIDES_${PN} += "u-boot-fw-utils"
+
+BBCLASSEXTEND = "native"
-- 
2.17.1

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

[Richard Purdie]

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? Should we remove the other recipe?

Cheers,

Richard

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

[Stefano Babic]

Hi Richard,

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
and u-boot-fw-utils. The need to syncronize u-boot with u-boot-fw-utils
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.

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

Best 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@denx.de
=====================================================================

Re: [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

Re: [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@denx.de
=====================================================================