> >> Is it useful to keep the option using cpio from the host? Why not
> >> always use cpio-native?
> > I guess it is a judgement call which tools to build and which tools to
> use from the host. Not building tools which are guaranteed to be on the
> host saves build time.
> I guess build time for cpio-native will be somewhere in the noise for
> a typical build. Avoiding the extra complexity (code + test and QA) of
> maintaining support for both cpio from the host and cpio-native would
> seem to be far more of an issue. There's no guarantee that cpio is
> available on the host (it currently needs to be installed manually if
> building within the ubuntu:16.04 docker image, for example).
Looking at the HOSTTOOLS in poky/meta/conf/bitbake.conf I see "cpio" is listed
among required tools. So at least for "poky" a missing cpio would/should
generate an error.
> > Also, the need for cpio-native with the reproducible options it is going
> to be fairly rare.
> I'm not sure I agree that wanting reproducible builds is a rare
> requirement but if it is then isn't eliminating a rarely used code
> path an argument *in favour of* switching to a single solution which
> supports both cases?
Agreed. I don't have a problem with defaulting to cpio-native,
it would solve a few problems as well, but I think some kind of consensus is
Openembedded-core mailing list