Created attachment 302 [details] base.bbclass checks for multiple (or) licenses There are a couple of packages with double or multiple license. This means that everybody can choose from a set of licenses. [example : qt4-embedded] LICENSE = "LGPLv2.1 | GPLv3" Well, this "or" operand doesn't work as i end up with this error in a GPLv3 incompatible build: [example : qt4-embedded] ERROR: Nothing PROVIDES 'qt4-embedded' ERROR: qt4-embedded was skipped: incompatible with license LGPLv2.1 | GPLv3 ERROR: Command execution failed: Traceback (most recent call last): File "/home/agherzan/work/wrs/yocto-adige/poky/bitbake/lib/bb/command.py", line 87, in runAsyncCommand commandmethod(self.cmds_async, self, options) File "/home/agherzan/work/wrs/yocto-adige/poky/bitbake/lib/bb/command.py", line 192, in buildTargets command.cooker.buildTargets(pkgs_to_build, task) File "/home/agherzan/work/wrs/yocto-adige/poky/bitbake/lib/bb/cooker.py", line 1111, in buildTargets taskdata.add_provider(localdata, self.status, k) File "/home/agherzan/work/wrs/yocto-adige/poky/bitbake/lib/bb/taskdata.py", line 371, in add_provider self.add_provider_internal(cfgData, dataCache, item) File "/home/agherzan/work/wrs/yocto-adige/poky/bitbake/lib/bb/taskdata.py", line 391, in add_provider_internal raise bb.providers.NoProvider(item) NoProvider: qt4-embedded For the case of excluding a certain license, base.bbclass should be modified in order to check if there is an "or" operand, and if it is, should check further if there are other non-excluded licenses. I will attach a patch that would solve this problem. Please check it and tell me if i should commit it.
(In reply to comment #0) > Created attachment 302 [details] > base.bbclass checks for multiple (or) licenses I'm sure this method might be a quick one, and if so, that could be a reason to stick with it, but it does seem to be duplicating at least some of the logic which already exists in the license parsing code used by license.bbclass.
(In reply to comment #1) > (In reply to comment #0) > > Created attachment 302 [details] [details] > > base.bbclass checks for multiple (or) licenses > > I'm sure this method might be a quick one, and if so, that could be a reason to > stick with it, but it does seem to be duplicating at least some of the logic > which already exists in the license parsing code used by license.bbclass. As i know that class is taken into consideration while building packages. Didn't see any license checked there for dependencies or excluded licenses. So i think my solution is ok.
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > Created attachment 302 [details] [details] [details] > > > base.bbclass checks for multiple (or) licenses > > > > I'm sure this method might be a quick one, and if so, that could be a reason to > > stick with it, but it does seem to be duplicating at least some of the logic > > which already exists in the license parsing code used by license.bbclass. > > As i know that class is taken into consideration while building packages. > Didn't see any license checked there for dependencies or excluded licenses. So > i think my solution is ok. I don't understand the point you're trying to make here. Whether license.bbclass excludes or not, the core logic is the same, and duplicating it arguably increases maintenance load. copyleft_compliance.bbclass uses the same parsing, and it *does* support exclusion.
Note: I don't have a strong opinion either way on this, I just wanted to make sure the decision was a conscious one.
Patch submitted by email to openembedded-core list: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/015128.html
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-January/015873.html
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-January/015953.html
commit 4005c3ff5e673f9d561026c76326054bd0a3a2b6