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