[Rpm-maint] [rpm-software-management/rpm] Allow file namesakes on symlink->dir replacement (#1684)

Michal Domonkos notifications at github.com
Tue May 18 13:45:16 UTC 2021


@dmnks commented on this pull request.



> @@ -633,7 +633,17 @@ assert(otherFi != NULL);
 		rConflicts = handleColorConflict(ts, fs, fi, i,
 						otherFs, otherFi, otherFileNum);
 
-		if (rConflicts && reportConflicts) {
+		/*
+		 * This may be a false positive (two separate files) if a
+		 * symlink is being replaced by a directory in one of these two
+		 * paths.  This check extends the one for removal conflicts in
+		 * handleInstInstalledFile().
+		 */
+		int reportThis = !(p == otherTe &&
+				   rpmtsFlags(ts) & RPMTRANS_FLAG_TEST &&
+				   rpmteHaveTransScript(p, RPMTAG_PRETRANS));

Unfortunately, that's the case, yes. I contemplated adding a specific check for the link -> dir case, but I thought it would be a bit more complicated, since you would have to iterate through each path component and check what its original vs. new status is. It could certainly be done and might not even be that difficult after all, but there's one catch that immediately comes to mind, which is - what happens if there are multiple such symlink replacements in the path? Stuff like that...

Basically what this patch does is it effectively *disables* the check for all self-conflicts within the same package, during test transactions (provided that there also is a %pretrans, but still). So, the worst that can happen if the check detects a valid conflict is that the test transaction passes silently and we only fail before the real one. Given that such self-conflicts are *probably* (I've got no hard data for that claim) pretty rare, it doesn't seem too dangerous. But sure, there is certain risk...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1684#discussion_r634396082
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20210518/10ea3d5d/attachment.html>


More information about the Rpm-maint mailing list