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.ha...@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
