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

[Mark Hatle]

On 2/14/17 1:18 PM, Alexander Kanavin wrote:
> On 02/14/2017 08:49 PM, Richard Purdie wrote:
>>
>> I think there is an assumption that these postinstalls are run under
>> set -e which may or may not be the case, I really don't remember.
>>
>> I do agree that if these are not run under -e, they are broken and that
>> they do indeed need fixing. What I think needs more discussion is how
>> we fix them. We have the set -e issue in more than just postinstalls.
> 
> I checked this with the master branch (e.g. current rpm5/smart 
> behavior). They are *not* run under set -e, and no amount of bogus 
> failing nonsense prior to that last chown command will make the 
> do_rootfs fail or trigger a first boot defer. So I think both need to be 
> fixed:

I just checked.  The set -e behavior SHOULD be the default in the system.
However, it looks like this must have broken somewhere along the way.

The initial implementation was calling '/bin/sh -e' as the default shell.  But
looking at what it is currently doing it appears to be calling '/bin/sh' instead.

> 1) postinst scriptlets need to run under -e

So this is a bug in the current implementation, and should be fixed.  RPM5 or 4....

> 2) deferral to first boot needs to be an explicit call in the scriptlets 
> (and not an implicit non-zero exit), so that actual script errors can be 
> reported and intercepted as errors.

There is a problem with this approach (mind you it's not really a huge problem,
but something to be aware of).  If the scriptlet needs to call another script to
defer, then you must carry a copy of that defer script (function) inline in the
current function.  This will dramatically increase the size of the scriptlet
components.

We have attempted to avoid this in the past, but it can be done.  (Note, because
it runs with /bin/sh, we need to make sure that various /bin/sh limitations are
accounted for.  So a function within a function may or may not be allowed.
Someone will have to check busybox for this.  It also means the call to the
postint_ontarget would need to be included in all scriptlets that use it.  So
we'd need to come up with standard behavior or process to make sure that happens.)

> Then the postinst_ontarget() can be a nice bonus to these two. There's 
> plenty of recipes where it would be enough - as a syntactic sugar that 
> prepends an unconditional first boot defer call during cross-install.

I don't object to this as standard OE practice.  (We still have to fix the -e
thing as well.)

There was another advantage though to the intercept script.  The ability to
install "someone elses RPM packages".

I.e. some random app provider who only releases RPM packages.  You can install
them and if their post install script fails (cross install) it gets staged for
first boot.

(This is useful, but far from a primary use-case.)

> Alex
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>