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

[Khem Raj]

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.

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.

> 
> 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.

> 
> Or is it best to not just build the examples and not worry about the 
> LGPL source code that's not in the output packages?
> 
> Also, I'm planning on a two patches for this package (libubox in 
> meta-oe/recipes-devtools); one which corrects the LICENSE (it's actually 
> BSD-1-Clause&BSD-3-Clause for the shipped binaries), and another which 
> updates to the latest stable release from upstream.  Since this is a new 
> ABI version/SOVERSION, should this be built as a separate recipe that 
> can exists alongside the older version?  (Not 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.

> 
> In particular I'm interested in procd as a tiny init with 
> process-handling (e.g. rewspawn, hotplug, network, and config change 
> triggers).
> 
> IIRC < 100K for procd stack vs. some # of MB's for systemd (not 
> including network).
> 
> 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,

> 
> 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

> Regards,
> 
> Daniel