[OE-core] [PATCH 04/10] lib/oe/package_manager: turn postinst_intercept warnings into failures for nativesdk

[Alexander Kanavin]

On Fri, 25 Jan 2019 at 16:38, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> > > There is a similar issue in multilib for target packages (a warning
> > > because qemu usermode support is missing):
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/214/steps/7/logs/warnings
> > >
> > > I'm as well not sure how to handle this:
> > > 1. Keep these two warnings as warnings so users see them in their
> > > local builds, but
> > >  add some kind of string pattern to AB so it excludes missing qemu
> > > support and missing wine support warnings.
> > >
> > > 2. Turn them into notes, which means they will go to the logs only,
> > > and users are not going to see them ever. On the other hand, the
> > > postinsts tend to
> > > create things like font caches and similar, which should not
> > > generally
> > > be needed at compile time (which is what SDKs are for).
> > >
> > > I'm leaning towards option two.
> >
> > I was leaning toward keeping them warnings and then suppressing them in
> > the cases where we know they don't work and are unnecessary (perhaps
> > with a variable like POSTINST_INTERCEPT_${PN} = "0" ?)
> >
> > That way if a user enables a package where it's not going to run and we
> > haven't previously evaluated it to be OK, they will at least see the
> > warning. I naively think this might help reduce the number of bugs
> > filed, or at least make them easier to triage :)
>
> I think this may be safer...

The postinst_intercepts are not executed per package (and accordingly
can't be suppressed in that manner), they are run as a set of scripts
available in scripts/postinst-intercepts/ during "populate_sdk" phase
for an image. I have sent a patch where both specific failures are
turned from warning to note (mingw, populating the target sysroot for
nativesdk) - both should be actually okay to suppress, as
a) mingw case never worked and has not been a problem as Joshua says;
b) target nativesdk sysroot should not be a problem either, as it will
be used just to build stuff, in a way similar to target Yocto builds,
where those intercept scripts are not executed either, at least not
until we populate a rootfs for the final image - and this has not been
an issue for anyone. The scripts all create some kind of 'caches'
which are only needed at runtime really.

Hope this helps,
Alex