action #95863

[qe-core] Improve conflict handling in update_install

Added by okurz 6 months ago. Updated 3 months ago.

Enhancement to existing tests
Target version:
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)


Motivation failed in tests like with

the to be installed rpm-ndb-4.14.1-29.2.x86_64 conflicts with 'rpm' provided by the installed rpm-4.14.1-29.46.x86_64 already explained that the conflict should be expected. in line 64 correctly states "Conflicts: rpm"

but the test was never adapted for that.

Notes from other people:

Jozef Pupava dzedro
The conflict handling can't solve everything when all packages are installed at once, some can't be installed in parallel like in this case ... zypper -n in -l rpm-ndb rpm-build rpm-32bit python3-rpm rpm-devel python2-rpm rpm -> the to be installed rpm-ndb-4.14.1-29.2.ppc64le conflicts with 'rpm' provided by the installed rpm-4.14.1-29.46.ppc64le

Stephan Kulow coolo
yes, because rpm-ndb and rpm are in conflict

Oliver Kurz okurz
and are expected to conflict, so what to do to make the test module not fail in such case?

Jozef Pupava dzedro
Yes, but sometimes there is kind of circle conflict between multiple packages which I could not solve
I was thinking about when there is conflict try to install packages each at the time

Marcus Meissner msmeissn
have 2 scenarios somehow? usually rpm-ndb is only for the container images though currently so ignore rpm-ndb for egular sles, but use for 15sp3 containers?

Stephan Kulow coolo
do we even test zypper patch within containers?

Jozef Pupava dzedro
The test just takes all the packages in the update and tries to install them, we could somehow split it but I don't know based on what ? I don't know about zypper patch within containers, maybe QAC could know.

Stephan Kulow coolo
... and if there are conflicts, it removes some if test whitelisted these conflicts

Acceptance criteria


action #95929: [qe-core] Investigate if update_install could be ran in the functional job groupRejectedapappas


#1 Updated by okurz 6 months ago

Added as watchers "dzedro" as involved person as well as "apappas" as test module maintainer

#2 Updated by dzedro 6 months ago

My idea to workaround this issue, would be something like this, to get rid of hardcoded conflict list.
In case of conflict try to install each package alone, before that remove all packages on the install list to avoid conflict between them.

@@ -185,7 +185,13 @@ sub run {

     # Install binaries newly added by the incident.
     if (scalar @new_binaries) {
-        zypper_call("in -l @new_binaries", exitcode => [0, 102, 103], log => 'new.log', timeout => 1500);
+        my $zypper_ret = zypper_call("in -l @new_binaries", exitcode => [0, 4, 102, 103], log => 'new.log', timeout => 1500);
+        if ($zypper_ret == 4) {
+            zypper_call("rm @new_binaries", exitcode => [0, 104], timeout => 1500);
+            foreach (@new_binaries) {
+                zypper_call("in $_", exitcode => [0, 4, 102, 103]);
+            }
+        }

#3 Updated by szarate 6 months ago

  • Target version set to QE-Core: Ready

Perhaps Jozef's idea is a good starting point.

#4 Updated by tjyrinki_suse 6 months ago

  • Status changed from New to Workable

#5 Updated by szarate 3 months ago

  • Status changed from Workable to Feedback
  • Assignee set to szarate
  • Target version changed from QE-Core: Ready to future

Santiago to check or ask if this happened again at some point in the future, because as of today, issue seems to be gone, if somebody wants to implement the workaround.

Looks like a circular dependency problem (if an update gets two conflicting packages in the same place, the issue seems to ocurr), another common case is when two packages are conflicting with eachother and are not in the conflict map, hence the table will have to be updated (A.K.A: Deal with it.)

Also available in: Atom PDF