Skip to contentSkip to conversation

rpm: fix failure to report file conflicts

PATCH Superseded Martin Vuille 2 participants 2 messages Mar 13, 2018

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 rpm: fix failure to report file conflicts

Problem: Conflicts between two packages trying to install different versions
of the same file are not detected. Both copies of the file are installed and the build is not deterministic because a different outcome results depending on which package is installed last.

Cause: All conflicts are treated as color conflicts, even when the files
are not ELF files. And one of the ways that these conflicts are handled is to install both conflicting files and letting the one installed last win.

Fix: Backport from upstream (see function handleColorConflict in
lib/transaction.c). Only treat as a color conflict when both of the conflicting files have a color and they do not both have the same color. Do not handle color conflicts by installing both conflicting files.

---
 .../rpm-fix-failure-to-report-file-conflicts.patch | 24 ++++++++++++++++++++++
 meta/recipes-devtools/rpm/rpm_5.4.16.bb            |  1 +
 2 files changed, 25 insertions(+)
 create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-fix-failure-to-report-file-conflicts.patch
meta/recipes-devtools/rpm/rpm/rpm-fix-failure-to-report-file-conflicts.patch new file +24 -0
new file mode 100644
index 0000000000..3f556ba97a
@@ -0,0 +1,24 @@
+--- a/lib/transaction.c
++++ b/lib/transaction.c
+@@ -411,7 +411,7 @@ assert(otherFi != NULL);
+ 
+ 		rConflicts = reportConflicts;
+ 		/* Resolve file conflicts to prefer Elf64 (if not forced) ... */
+-		if (tscolor != 0) {
++		if (tscolor != 0 && FColor != 0 && oFColor != 0 && FColor != oFColor) {
+ 		    if (FColor & prefcolor) {
+ 			/* ... last file of preferred colour is installed ... */
+ 			if (!iosmFileActionSkipped((iosmFileAction) fi->actions[i])) {
+@@ -431,12 +431,6 @@ assert(otherFi != NULL);
+ 			    otherFi->actions[otherFileNum] = FA_CREATE;
+ 			fi->actions[i] = FA_SKIPCOLOR;
+ 			rConflicts = 0;
+-		    } else
+-		    {
+-			/* ... otherwise, do both, last in wins. */
+-			otherFi->actions[otherFileNum] = FA_CREATE;
+-			fi->actions[i] = FA_CREATE;
+-			rConflicts = 0;
+ 		    }
+ 		    done = 1;
+ 		}
meta/recipes-devtools/rpm/rpm_5.4.16.bb +1 -0
index 497af8e055..296f6b8a97 100644
@@ -120,6 +120,7 @@ SRC_URI += " \
 	   file://0001-system.h-query.c-support-nosignature.patch \
 	   file://rpm-ensure-rpm2cpio-call-rpm-relocation-code.patch \
 	   file://0001-macros-add-_gpg_sign_cmd_extra_args.patch \
+	   file://rpm-fix-failure-to-report-file-conflicts.patch \
 "
 
 # OE specific changes
Signature · 1 line
2.13.6
#1 lore raw

✗ patchtest: failure for rpm: fix failure to report file conflicts

== Series Details ==

Series: rpm: fix failure to report file conflicts
Revision: 1
URL : https://patchwork.openembedded.org/series/11375/
State : failure

== Summary ==

Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures:

* Issue A patch file has been added, but does not have a Signed-off-by tag [test_signed_off_by_presence]
Suggested fix Sign off the added patch file (meta/recipes-devtools/rpm/rpm/rpm-fix-failure-to-report-file-conflicts.patch)

* Issue Added patch file is missing Upstream-Status in the header [test_upstream_status_presence_format]

  Suggested fix    Add Upstream-Status: <Valid status> to the header of meta/recipes-devtools/rpm/rpm/rpm-fix-failure-to-report-file-conflicts.patch
  Standard format  Upstream-Status: <Valid status>
  Valid status     Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where]

If you believe any of these test results are incorrect, please reply to the mailing list ([email protected]) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...).

---

Guidelines:     https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite:     http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe