Re: [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping


Andre McCurdy
 

On Fri, Mar 26, 2021 at 11:12 AM Richard Purdie
<richard.purdie@...> wrote:

On Fri, 2021-03-26 at 18:06 +0000, Peter Kjellerstedt wrote:
-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: den 25 mars 2021 17:52
To: Peter Kjellerstedt <peter.kjellerstedt@...>; Oleksiy Obitotskyi -
X (oobitots - GLOBALLOGIC INC at Cisco) <oobitots@...>; Luca Bocassi
<luca.boccassi@...>; openembedded-core@...
Cc: bluelightning@...; Khem Raj <raj.khem@...>
Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
recipe to allow bootstrapping

On Thu, 2021-03-25 at 16:19 +0000, Peter Kjellerstedt wrote:
-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: den 25 mars 2021 15:27
To: Peter Kjellerstedt <peter.kjellerstedt@...>; Oleksiy
Obitotskyi -
X (oobitots - GLOBALLOGIC INC at Cisco) <oobitots@...>; Luca
Bocassi
<luca.boccassi@...>; openembedded-core@...
Cc: bluelightning@...; Khem Raj <raj.khem@...>
Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
recipe to allow bootstrapping

On Thu, 2021-03-25 at 14:22 +0000, Peter Kjellerstedt wrote:
-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: den 25 mars 2021 10:34
To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
<oobitots@...>; Luca Bocassi <luca.boccassi@...>;
openembedded-core@...
Cc: bluelightning@...; Peter Kjellerstedt
<peter.kjellerstedt@...>; Khem Raj <raj.khem@...>
Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in
separate
recipe to allow bootstrapping

On Thu, 2021-03-25 at 09:17 +0000, Oleksiy Obitotskyi -X (oobitots
-
GLOBALLOGIC INC at Cisco) wrote:
Could you look into this warning.

WARNING: util-linux-2.36.2-r0 do_package_qa: QA Issue: util-
linux-
dev
rdepends on util-linux-libuuid-dev, but it isn't a build
dependency?
[build-deps]

https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226

That failure was my fault when testing some fixes.

I've sent out a patch which renames util-linux-uuid to util-linux-
libuuid
and sorts out the license issue Peter reported.
I don't mind the recipe being renamed and cleaned up, but I would
prefer
to see my entire patch for the license parts being either integrated
before
this or squashed into it, whichever you prefer. It does not make
sense
to
use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-
linux,
and setting the other LICENSE variables in util-linux.inc no longer
makes
sense as they are only relevant for util-linux.
I'm torn on that. Code with the other licenses is present, just not
used
in the final output and I personally suspect that having one
LIC_FILES_CHKSUM
is going to be easier to maintain in the future rather than two
separate
ones.
I actually checked all the files that go into -dev and -src before
suggesting
this change, and all files are either marked as public domain or use a
BSD-3-Clause license.
There is a difference between what ends up in ${S} and what ends up in the
binary packages. LICENSE clearly governs the latter. Its the scope of
LIC_FILES_CHECKSUM which there are differences of opinion on.
Well, the latter governs what ends up in ${PN}-lic, so having a lot of
unrelated (to the installed packages) license files in LIC_FILES_CHECKSUM
does not make sense (to me). If everything that is built and (possibly)
installed and thus distributed is covered by BSD-3-Clause licenses, why
should ${PN}-lic include a lot of license files for unrelated code?
I hadn't considered ${PN}-lic :(.

We can't win. If we change LIC_FILES_CHKSUM we'll see complaints from
people scanning the code that there are licenses present in WORKDIR that
are not in LIC_FILES_CHKSUM.
If there's code in the upstream tar file etc which is not involved at
all in the build of the one particular sub component you're interested
in then this type of complaint can be solved by removing the unused
code from ${S} as part of do_patch.

If we don't change it, ${PN}-lic does give
more information than necessary. I still think the latter is probably
safer and makes recipe upgrades easier.

Licensing in general needs a step back and an overhaul. Sadly people are
generally only prepared to do this piecemeal solving their specific
issue rather than the general case and big picture.

Cheers,

Richard





Join openembedded-core@lists.openembedded.org to automatically receive all group messages.