On 01/02/18 08:38 AM, Burton, Ross wrote:
On 1 February 2018 at 12:55, Daniel F. Dickinson <csho...@thecshore.com
<mailto:csho...@thecshore.com>> wrote:
I'm wondering if is doable and would be accepted to add a "tiny"
DISTRO_FEATURE that automatically does PACKAGECONFIG += "tiny", and
packages which honour this make choices that build smaller editions
and/or create smaller binary sub-packages than default (i.e. things
that can be split out of build packages are, so that a -core or
-base package has only the minimum, and a one uses metapackages to
install expected packaging (so ${PN} would by default RDEPEND on
${PN}-base and other sub-packages (or other recipes
packages/sub-packages) that give the 'usual' use case for the
package, but can be managed in parts for systems that are quite small.
Or is the splitting into sub-parts preferred anyway and patches to
make smaller splits would accepted relatively easily, but usually
just don't get done because it's more work to have more sub-packages
and so it just doesn't get done to the level a project like OpenWrt
pieces things up, and OpenEmbedded usually has more space available
than a typical OpenWrt device?
I think PACKAGECONFIG[tiny] would really translate into different
things in different packages (hence the idea of having a top-level
flag that
makes it easier to do across the board rather than having to specify
specific flags for each recipe, except in exceptional
circumstances), although something like nossl should perhaps be a
separate top-level flag since even if you want small you probably
want some kind of ssl, but there may be relevant use cases where
nossl would be wanted but isn't just about size. With -tiny one
could perhaps emphasize the choice of smaller SSL libraries like
mbedtls and wolfssl (cyassl) when they are an option and warn (or
refuse to build) if a big library like openssl can't be avoided.
I feel that DISTRO_FEATURES=tiny is too coarse: you may want a tiny
busybox but a fully-featured wget, or whatever.
Also PACKAGECONFIG[tiny] doesn't really explain *what* it's doing, and
may end up doing many things at once. Does a tiny systemd disable
networkd? What if you want as tiny as possible, but with networkd?
Fine grained PACKAGECONFIGs and/or subpackages as appropriate are
definitely the way forwards in my opinion.
I guess the question is would it be useful to have a flag that chooses
a 'typical' tinyness but can be overridden (I'm think here of avoiding
having to specify huge numbers of PACKAGECONFIGs for a typical tiny
case, when really you want most of the 'normal' tinyness with some
tweaks. What I'm think is that "tiny" really should just change the
defaults for PACKAGECONFIG etc, but like the defaults can be easily
overridden.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
