[Openembedded-architecture] Changes that switching from smart to dnf will cause

[Alexander Kanavin]

On 02/14/2017 04:29 PM, Richard Purdie wrote:

> We have situations where we simply don't know in advance if a given
> postinst is going to be able to work at rootfs construction time or
> not. As an example, take the fontconfig postinst. This runs under qemu
> emulation. That emulation can work for some arches and not others. We
> don't really want to have to mark things up to indicate which work and
> which don't. Worse, some target optimisations might work and others
> might not.

I guess you meant the postinsts provided by fontcache.bbclass and other 
*cache.bbclass files? Those postinsts do not actually call qemu, and so 
will *not* fail in any circumstances.

What they do is call postinst_intercept with a name of different 
scriptlet. That will trigger an execution of this different scriptlet 
after all packages have been installed, and then the qemu will actually 
run. If that fails, *then* the original postinst is deferred to first boot.

For those who don't want to use this (rather complicated) approach, 
there's a more straightforward way to run things and allow them to fail. 
Just needs to be documented:

pkg_postinst_PACKAGE() {}
{
    if D is defined: # cross-install
        try_something_that_is_allowed_to_fail
        if that_something_has_failed:
             # this defers to first boot explicitly
             # without failing the script
             postinst_intercept defer_to_first_boot PACKAGE
     else # target
        do_something on target
}

> I'd therefore like to see this change disentangled from the rpm change
> and considered separately, if its something we really want to do which
> I remain unconvinced about.

Sure, I can do that.

Alex