[oe] Per-binary-package LICENSE? and/or dependent on PACKAGECONFIG?

[Daniel F. Dickinson]

On 30/01/18 01:50 AM, Khem Raj wrote:
> 
> 
> On 1/29/18 5:38 PM, Daniel F. Dickinson wrote:
>> Hi all,
>>
>> I have a question about packages which by default don't ship e.g. LGPL 
>> code in their binaries, but if a configure option is turned on then 
>> the package generates examples / test programs that are LGPL (in this 
>> case due to a shell script from shunit2).
>>
>> How can you define the LICENSE so that it's correct in each case?
>>
>> Is it possible to do e.g. LICENSE_ LICENSE_${PN}-examples, etc?
> 
> yes, you should be able to define per package license. May be its better 
> to separate such output artifacts into separate packages and then use 
> the above LICENSE_packagename constructs.

Yes, that is what I was thinking.

> 
> Now, if the license gets changed for binary due to some configure option
> then its not well tracked. Probably its better to have a separate recipe 
> for such cases.

Well, the configure option would end up creating (by default off) the 
${PN}-examples package so the above should still work, without needing 
an entirely separate recipe.  Now if it were the case there were a 
binary that had one license in one case and a pair of licenses in 
another, it'd be as you say.

> 
>>
>> What about making LICENSE contents conditional on PACKAGECONFIG
>> (for if the offending examples are built)?
> 
> If packages are well defined then you might not need this.
> 
>>
[snip]
>> that there are likely many users of this library yet; it really is 
>> primarily useful for the work I'm doing on munging Openwrt packages 
>> like procd and netifd which depend on ubus and libubox so they are 
>> useful outside Openwrt.
> 
> I think these packages should be left to meta-openwrt. They are not so 
> common and meta-oe is not right place for them. So send a patch to 
> delete them.

Ok, that makes sense.  I have some ideas on how to have both the openwrt 
case and the standalone case in meta-openwrt.  For that meta-openwrt vs. 
standalone procd though, I'm more interested in getting things in shape 
so that hopefully one can build a system as trimmed down as openwrt, and 
therefore that maybe openwrt can become part of the openembedded 
ecosystem instead of being an isolated thing.

[snip]

>> The real question is whether there is any *modern* *Linux* embedded 
>> hardware where that's a big deal.  Obviously old routers with 8MB 
>> flash and 128 MB RAM it matters, but I'm have no insight into how 
>> common that size of hardware is in any new development.
> 
> there still are designs which are relevant to this size, especially 
> smaller wifi APs for e.g mesh networking, so it does have an appeal but 
> its not a common case anymore,

Hmmm....well I do have some hardware that's small enough that systemd 
could be problematic (128 to 256 MB RAM, and 16 - 32 MB flash), so I 
think I'll continue on with the meta-openwrt work for those cases.

>> If not much, then a better road for me would be to deal with UX for 
>> headless (e.g. network/web) systemd builds.
> 
> probably, is a good place for slightly bigger h/w with say 512M+ ram

This is more the space I'm interested in for forward-looking 
development, and I have a few projects in mind, but working meta-openwrt 
is a good way to get a handle on how things integrate in openembedded 
(since I have to under the core to make the openwrt stuff fit).

Regards,

Daniel