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

[Herve Jourdain]

Hi Daniel,

OK, I'll send what I've done to fix this for me tomorrow - it's basically
what we have discussed here, modification of 2 lines.

Regarding the possibility that the whole scheme might fail because of
"package already installed" during a retry, I won't try anything yet,
because I'd like to understand why it was done this way to begin with -
there may be some good reasons that I just can't find, so I'd rather be on
the safe side.
This said, the way things are done would work if all packages would fail
installation, because then none would become "already installed". But since
I'm not sure what exact kind of use cases / tests are supposed to be working
or not here, I'd rather postpone "fixing" that part.

If anyone on the list knows the history on that part, though, I'd be
interested to learn the background on the design, and the rationale of the
implementation.

Herve

-----Original Message-----
From: Klauer, Daniel [mailto:Daniel.Klauer at gin.de] 
Sent: mercredi 8 juin 2016 17:43
To: Herve Jourdain <herve.jourdain at neuf.fr>;
openembedded-core at lists.openembedded.org
Subject: Re: [OE-core] [PATCH] smartpm: Don't ignore error if RPM
transaction fails without problems

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...
> 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
=