On Fri, 2022-02-18 at 11:41 -0800, Saul Wold wrote: > As a follow-on to yesterday's email and replies, I would like to make > the following proposal for dealing with the changes to > INCOMPATIBLE_LICENSE and associated variables. > > Current Usage: > > INCOMPATIBLE_LICENSE is a list of licenses that are considered > incompatible with a distro's requirements. This is used to compare > against packages built by a given recipe. > > A set of exception variables based on the license name (currently > WHITELIST_<license>) that contains a list of recipes that will be > checked against the current recipe (PN) being evaluated. If it's in > that list then all packages in that recipe will be built and included > and the rest of the evaluation will be skipped. > > Otherwise, the packages (PKGS) from the recipe will be evaluated to see > if any have a package specific license (LICENSE:<pkgname>). If a package > has a license other than the INCOMPATIBLE_LICENSE the recipe will be > built and any packages with the INCOMPATIBLE_LICENSE will be excluded > from being packaged in package.bbclass via LICENSE_EXCLUSION-<pkgname> > internal variable. > > The exception is predominately used for GPLv3 related packages, based on > the emails replies overnight. > > > Proposal: > > Keep the existing INCOMPATIBLE_LICENSE variable with the same behavior. > The values in INCOMPATIBLE_LICENSE should be SDPX normalized license > strings. > > As Richard has already suggested an alternative variable that is more > meaningful: INCOMPATIBLE_LICENSE_EXCEPTION with an a <pkg>:<spdx_lic> > value. Rename the LICENSE_EXCLUSION-<pkg> variable to make it clear that > it is an internal variable. The usage of the _EXCEPTION variable should > contain pkg names not recipe name. ** This would be an important change ** > > Clean up code as appropriate to ensure the exceptions are handled once > and identified during parsing. > > I will start working on the implementation, Monday is a holiday in the > US, so this should give sometime for this to be reviewed for Tuesday.
Thanks Saul, from my perspective I think this is a good balance between cleaning up the syntax and other issues whilst being practical to implement and test in the time frames available. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1479): https://lists.openembedded.org/g/openembedded-architecture/message/1479 Mute This Topic: https://lists.openembedded.org/mt/89240702/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
