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

[Mark Hatle]

On 2/17/17 11:01 AM, Alexander Kanavin wrote:
> On 02/17/2017 07:26 PM, Mark Hatle wrote:
>>> 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.
> 
> Why? I'm not able to understand why this needs to be done. I'm calling 
> out to external script with the name of the package to do the deferral, 
> and the deferral happens as expected, both in ad hoc testing, and in 
> oe-selftest test case that checks specifically for this.

Who owns the external script?  How is or would it be made available to an
'installer' (think anaconda), etc.

This is why typically we've included the contents in the scriptlets in the past,
so the RPM packages themselves are standalone, other then standard tools -- or
things that recipe either depends on or provides on it's own.

>> 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.
> 
> Ugh, maybe it's better to install the package on target to begin with? 
> Or another option: extract their rpm contents with rpm2cpio, and rebuild 
> it properly through a recipe.

Due to support issues or other reasons, often this is not allowed by the
application vendor.  (Yes it's a mess.)

However, where possible we do try to push people toward repacking them uses
extraction and recipes.

> Generally, such '3rd party RPMs' are very prone to breakage, even on 
> desktop distros.

Yes they are.

In some places today we handle this using post rootfs install scripts that
simply invoke RPM (or smart) with the right arguments to pick up this external
RPM and add it to the system.

(As I mentioned, this is something we can do today..  I don't really encourage
it, but I know it gets used occasionally.)

--Mark

> Alex
>