@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_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
