[OE-core] [PATCH] smartpm: Don't ignore error if RPM transaction fails without problems

Herve Jourdain herve.jourdain at neuf.fr
Wed Jun 8 16:17:26 UTC 2016


Hi Mark,

In my case, the issue was due to an empty problem list, which after Daniel's fix did trigger a retry, which failed because the packages were already installed.
But the code for a non-empty problem list does also trigger a retry, and I suppose it would run also in the same "package already installed" issue, if it were to be triggered - not sure though, since I never had that case yet.
Do you think we need to check and potentially fix that case? Or shall we remove the retry feature altogether instead?

Hervé

> Le 9 juin 2016 à 00:05, Mark Hatle <mark.hatle at windriver.com> a écrit :
> 
>> On 6/8/16 10:43 AM, Klauer, Daniel wrote:
>> Hello,
>> 
>>> You also need to add another check just before raising the error, or you
>>> would end up getting an "unknown error" raised there.
>>> I basically replaced:
>>> -        if (probs is not None) and (not retry):
>>> +       if (probs is not None) and ((len(probs) != 0) or not
>>> sysconf.has("attempt-install", soft=True)) and (not retry):
>> 
>> Hmm, it sounds like the attempt mode wants to ignore installation failures
>> (empty problems list) like before the patch, which makes sense to me. Afterall,
>> attempt mode wants to try installation and ignore failures. So it seems good to
>> fix this regression too.
>> 
>> However, I wonder why it never ignored a non-empty problems list, which would
>> also trigger an error. Maybe that case just never happens in practice, because
>> it's always just file conflicts. Those trigger a retry, which prevents the error
>> from being raised.
>> 
>>> BUT reflecting on the whole scheme, I'm wondering how it will work in case
>>> of file found conflict, since the problem package gets removed from the
>>> list, but the list is committed again, with most packages already
>>> installed...
> 
> File conflicts are discovered prior to the transaction being committed
> (installation time).  Problems reported during installation are 'different' (and
> generally do not happen).  I'm not sure if a pre/post install failure, bad
> package (signature or otherwise) or whatever would do here.  I'm not sure it's
> been tested.
> 
> (The items above can't generally happen based on the way the system is designed..)
> 
> --Mark
> 
>>> I therefore wonder that there could be the same error that I got in the end,
>>> i.e failing with package already installed - which should not fail for
>>> attempt only.
>> 
>> Indeed, I'm curious about that too...
>> 
>> If you could put together the patch, that would be great and fine with me.
>> 
>> Thanks,
>> Daniel
>> 
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



More information about the Openembedded-core mailing list