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

[Joshua Watt]

On Fri, 2019-01-25 at 17:10 +0100, Alexander Kanavin wrote:
> 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.

I probably should have been a little more specific: I was thinking that
POSTINST_INTERCEPT_${PN} = "0" would prevent the creation of the
scripts at packaging time, not try and suppress them at rootfs creation
time. The idea would be to add that to relevant recipes with a
appropriate override in a .bbappend in meta-mingw. I'm not familiar
enough with multilib; is there a an appropriate override that could be
use there?

I think this would also have the advantage that mingw32 specific logic
in package_manager.py could be removed; we'll just suppress the
postinst intercept scripts in meta-mingw and any that aren't will
generate the typical failure warning.


> 
> Hope this helps,
> Alex
-- 
Joshua Watt <JPEWhacker at gmail.com>