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
--
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
