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:
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.
<richard.purdie@...> wrote:
If there's code in the upstream tar file etc which is not involved at
On Fri, 2021-03-26 at 18:06 +0000, Peter Kjellerstedt wrote:I hadn't considered ${PN}-lic :(.-----Original Message-----Well, the latter governs what ends up in ${PN}-lic, so having a lot of
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:Obitotskyi ------Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: den 25 mars 2021 15:27
To: Peter Kjellerstedt <peter.kjellerstedt@...>; OleksiyBocassiX (oobitots - GLOBALLOGIC INC at Cisco) <oobitots@...>; Lucaseparate<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-recipe to allow bootstrapping
On Thu, 2021-03-25 at 09:17 +0000, Oleksiy Obitotskyi -X (oobitotslinux-GLOBALLOGIC INC at Cisco) wrote:Could you look into this warning.
WARNING: util-linux-2.36.2-r0 do_package_qa: QA Issue: util-dependency?devrdepends on util-linux-libuuid-dev, but it isn't a buildpreferhttps://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226[build-deps]libuuid
That failure was my fault when testing some fixes.
I've sent out a patch which renames util-linux-uuid to util-linux-and sorts out the license issue Peter reported.I don't mind the recipe being renamed and cleaned up, but I wouldsenseto see my entire patch for the license parts being either integratedbeforethis or squashed into it, whichever you prefer. It does not makelinux,touse the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-usedand setting the other LICENSE variables in util-linux.inc no longermakessense as they are only relevant for util-linux.I'm torn on that. Code with the other licenses is present, just notLIC_FILES_CHKSUMin the final output and I personally suspect that having oneseparateis going to be easier to maintain in the future rather than twosuggestingones.I actually checked all the files that go into -dev and -src beforethis change, and all files are either marked as public domain or use aThere is a difference between what ends up in ${S} and what ends up in the
BSD-3-Clause license.
binary packages. LICENSE clearly governs the latter. Its the scope of
LIC_FILES_CHECKSUM which there are differences of opinion on.
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?
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.
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