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

[Mark Hatle]

On 2/14/17 11:44 PM, Anders Darander wrote:
> Hi,
> 
> I'm primarily responding to your proposed pkg_postinst_ontarget_${PN},
> as I'm a little bit worried.
> 
> * Alexander Kanavin <alexander.kanavin at linux.intel.com> [170214 15:04]:
> 
>> 2. Rpm 5.x is replaced with rpm 4.x. This is done for two major reasons:
> 
>> - DNF is API incompatible with Rpm 5.x and porting it and maintaining the
>> port is non-trivial.
> 
>> - rpm 5.x itself is more or less unmaintained both in the upstream and in
>> Yocto. There is no community around it, and Yocto is the sole remaining
>> user. I think this is a stronger argument for moving away from it, than any
>> technically superior features rpm 5.x may have over 4.x (not sure what those
>> would be).
> 
> Mark Hatle should comment on this one. I know that there's been quite
> some issues with RPM4 and cross-compilation / embedded usage...

Based on my last investigation into RPM4 (a few months back).  I do expect some
problem with MIPS support.  (Specifically mips64 n32.)  Similarly there may be
some issues w/ x32 support, but I didn't specifically look for that.

RPM4's configuration seems to be more simplified then it used to be, so that
certainly helps -- but we need to be careful to look for internal embedded host
paths.  As this will break things over time.

The case I keep running into is an embedded path in rpmpopt is causing customer
automounters to try to go to the builder/developers home directory which is not
available for some reason.  So every time rpm is invoked there is a 4-5 minute
stall.

So it's vital we look for things like that.

>> 6. Things that need to run on target during package installation should go
>> into pkg_postinst_ontarget()
> 
>> Previously, the way to achieve this was:
> 
>> pkg_postinst_PACKAGENAME() {
>>      if [ x"$D" = "x" ]; then
>>           # Actions to carry out on the device go here
>>      else
>>           exit 1
>>      fi
>> }
> 
>> The new way is simply:
> 
>> pkg_postinst_ontarget_PACKAGENAME() {
>>      # Actions to carry out on the device go here
>> }
> 
> Do you plan to convert the old pkg_postinst_${PN} to this one?
> How are they supposed to work on a read-only rootfs?
> 
> I'd say, ensure that the pkg_postinst_${PN} actually fails if something
> goes wrong, i.e. add `set -e`, and fix up everything that fails during
> rootfs...
> 
> Regarding your examples with fontconfig etc, luckily, I've not had to
> use those yet, but I mmight have to do that in the near future. If so,
> they'll have to run during rootfs creation and not on the target.
> 
>> The old way still works, but is deprecated and will produce a warning. I
>> understand this change is orthogonal to dnf, but the current design is
>> flawed and now is a chance to fix it. The reasons are:
> 
>> 1) Code is hard to read; it is not obvious that 'if D is defined then exit
>> 1' means 'defer what follows to first boot during package cross-install'.
> 
> As with everything, documentation and experience helps... But sure, for
> a newcomer this might look strange.
> 
>> 2) Worse, this hides actual errors in the scriptlets; there is no difference
>> between scriptlet failing because it's intended to be run on target and
>> scriptlet failing because there's a bug or a regression somewhere. I've
>> already found broken scriptlets where the brokenness was hidden this way (in
>> meta-selftest/recipes-test/postinst/postinst_1.0.bb)
> 
> Ensure that they're run under `set -e`...
> 
>> Plain pkg_postinst() without special tricks works exactly as before.
> 
> In the worst case, there might be followup patches trying to convert
> pkg_postinst_ontarget_${PN} back to pkg_postinst_${PN}, for the
> ro-rootfs case.
> 
> Cheers,
> Anders
>