A table lock seems like a very big hammer here. We don't actually do that anywhere else.

Do you have a reproducer? Some example hub traces?

I wonder if this would be helped by sorting rpm lists before passing them to add_external_rpm.

I wasn't able to reproduce it reliably. Total reproducer is your script, but don't have any real-world examples. @ignatenkobrain anything in your logs?

You're right that kiwi is doing the rpm retrieval in different way than the other task (getImagePackagesFromCache). I can add sorting there, but don't have reliable way to test that it really helped.

We previously had very similar deadlocks when updating buildroots. These were solved by sorting the inputs. I'd prefer to try the same here before we add locking.

If we do add locking, I'd rather not have the full table lock. A better option might be the upcoming lock functionality in #3786, but again, lets try the sorting first.

Absent a reproducer, we can't verify that any fix will work except by getting the reporter to test it out.

I've also added some questions in the original issue. It would be nice to have precise details about before we go making complex changes.

I've replaced it with sorting on input for now.

The current solution is so different that it might deserve a separate PR. Or at least fix the title of this one and squash out the reverted commit.

Sorting these inputs in the builder plugin seems at least harmless, but it would probably be simpler to just add

rpm_ids.sort()

in importImageInternal before the bulk inserts into archive_rpm_components. This would be directly analogous to the measure we have in BuildRoot._setList.

filed #3882

closed in favour of #3882