Re: [Buildroot] [PATCH v2 1/1] package/frr: update to 9.1.1

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello Vincent,

On Thu, 22 Aug 2024 18:36:30 +0200
Vincent Jardin <vjardin@free.fr> wrote:

> Update to the latest 9.x version.
> Protobuf becomes mandatory.
> 
> Update hash for COPYING too
> 
> Signed-off-by: Vincent Jardin <vjardin@free.fr>

Thanks for the patch, but it will need more work, see below.

> diff --git a/package/frr/Config.in b/package/frr/Config.in
> index 0afd8c61a2..462c58f0da 100644
> --- a/package/frr/Config.in
> +++ b/package/frr/Config.in
> @@ -10,6 +10,7 @@ config BR2_PACKAGE_FRR
>  	select BR2_PACKAGE_LIBYANG
>  	select BR2_PACKAGE_READLINE
>  	select BR2_PACKAGE_JSON_C
> +	select BR2_PACKAGE_PROTOBUF_C

When you "select" an option, you have to replicate its depends on. So
here, BR2_PACKAGE_PROTOBUF_C has:

        depends on BR2_INSTALL_LIBSTDCPP
        depends on BR2_TOOLCHAIN_HAS_THREADS
        # host-protobuf only builds on certain architectures
        depends on BR2_PACKAGE_HOST_PROTOBUF_ARCH_SUPPORTS
        depends on BR2_HOST_GCC_AT_LEAST_7 # c++17 for host variant

So you need to replicate those dependencies to BR2_PACKAGE_FRR:

        depends on BR2_INSTALL_LIBSTDCPP # protobuf-c
        depends on BR2_TOOLCHAIN_HAS_THREADS # protobuf-c
        depends on BR2_PACKAGE_HOST_PROTOBUF_ARCH_SUPPORTS # protobuf-c
        depends on BR2_HOST_GCC_AT_LEAST_7 # protobuf-c

And update the Config.in comment as follows:

comment "frr needs a toolchain w/ threads, dynamic library, C++, host gcc >= 7"
        depends on BR2_PACKAGE_HOST_PROTOBUF_ARCH_SUPPORTS
        depends on BR2_TOOLCHAIN_HAS_SYNC_4
        depends on BR2_USE_MMU
        depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS || \
		!BR2_INSTALL_LIBSTDCPP || !BR2_HOST_GCC_AT_LEAST_7

> diff --git a/package/frr/frr.hash b/package/frr/frr.hash
> index 4a61084bae..eb88507a9f 100644
> --- a/package/frr/frr.hash
> +++ b/package/frr/frr.hash
> @@ -1,3 +1,3 @@
>  # Locally calculated
> -sha256  7ae9d8bafc65bb5d0f21061ac61dbc6cf93b2b05a5dae9e5eec72ed42388551e  frr-8.5.4.tar.gz
> -sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  COPYING
> +sha256  6eb254c72dca867fefffd5ded80a6c2d5ce8df223ce93263302db4b8bfbb19c4  frr-9.1.1.tar.gz
> +sha256  7bf053957d6c38e39a06a112c60ff35b228d3bd03edbe8c9a03508b051128d16  COPYING

The change of license file hash must be explained in the commit log.
But actually, it is quite tricky. Basically the whole text of the GPLv2
has been replaced by just:

=====

The FRRouting project consists of parts with various licenses.  Any particular
file's license should be indicated at the top of the file with an SPDX License
identifier.

The full text of all licenses used can be found in doc/licenses.

The composite work (binary) resulting from compiling FRR is thought to always
be distributable under GPLv2 or later.  However, please note that this is
simply an expression of the community's best-effort understanding, it is not a
legal statement, guarantee, or advice of any kind.  If necessary, please
familiarize yourself with the specifics and/or consult a lawyer.

Also please be advised that FRR's documentation is, for historical reasons,
licensed under a custom (but relatively permissive) license.  This license
dates back to the GNU Zebra project and cannot easily be changed into something
more common, short of rewriting the entire documentation.

====

So it means that FRR_LICENSE must be changed to GPL-2.0+.

Also, it probably means that all files in doc/licenses/ must be added
to FRR_LICENSE_FILES most likely, and their hash added.

One thing that's a bit worrying is that they have the GPL-3.0 license
text in there. I don't know which parts of their code base has a
GPL-3.0 license, but if it's linked into the "composite work", then its
license clearly isn't GPL-2.0+.

It would be useful to clarify which part are under which license,
especially the GPL-3.0 part, which some people may not want to have in
their builds.

So this bump that looked simple is in the end not that trivial I'm
afraid :-/

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot