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

[Mark Hatle]

On 2/14/17 6:29 AM, Richard Purdie wrote:
> On Tue, 2017-02-14 at 16:04 +0200, Alexander Kanavin wrote:
>> 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
>> }
>>
>> 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'.
>>
>> 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)
>>
>> Plain pkg_postinst() without special tricks works exactly as before.
> 
> I'm not sure I agree with this. I do understand your concerns however
> its not quite as clear cut as you make out.
> 
> 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'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.

Just a 'me too'.  I think moving the post install to it's own commit is a really
good idea.

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