conflict checker: skip packages obsoleted by packages under test (#20) #21
Conversation
|
I tested that this prevents the bogus failures with https://bodhi.fedoraproject.org/updates/FEDORA-2024-e9a5fdd899 . I can reproduce the 'errors' without this patch, with this patch the check is clean. Can anyone think of any cases where this would cause false passes? Off the top of my head there's arguably one - it's not entirely true that "Conflicts cannot happen between solvables with the same name", in the case of parallel-installable packages like kernel. If a new kernel package would conflict with the current kernel package that's arguably something we should detect, because it would cause problems for a user. But this is already a problem in the current code, this change doesn't make it worse. |
…ora-ci#20) As explained in issue fedora-ci#20, when checking for conflicts, it's not enough to skip only existing packages with the same name as the one they are being checked against. We should skip all existing packages that the set of packages being tested would replace. Fortunately, we already have `_select_obsoleted_by` to do this exact job, so let's just use it here. We keep the existing 'skip if the names are the same' check to avoid generating confusing results if the update under test contains a package with the same name as an existing package but with a *lower* EVR. This is wrong, but we should leave it to be caught by other checks; handling it here would give a rather confusing failure about file conflicts between the two packages, which the packager might not understand. Signed-off-by: Adam Williamson <[email protected]>
AdamWill
force-pushed
the
conflicts-filter-obsoleted
branch
from
9754b0a to
9cc95ad
Compare
|
ugh, so the failed test here is a real thing. It's failing the test that backs https://bugzilla.redhat.com/show_bug.cgi?id=1502458 . The scenario there wants us to find conflicts with a package that the update would replace. So...that's awkward. I'm really not sure how we ought to handle this, now. I kinda want to say that not causing false failures like the one this fixes is more important than not catching conflicts like the one in 1502458 , but maybe I'm biased. Would be good to know what others think. I guess one option is to only exclude packages that are literally obsoleted by packages in the update (and not exclude all packages that are replaced by a higher NVR in the update from all the checks, instead relying on the 'don't test packages of the same name against each other' check there). That would address this specific case, I think. But I dunno if it feels a bit...artificial? |
|
mmm...thinking about it more, I guess you could say this update is theoretically subject to the problem from 1502458 . Say you have compiler-rt-18.x installed and you (for some reason) decide to install compiler-rt18 ; you will hit a conflict, dnf will not force an upgrade to compiler-rt-19.x in that case. If you do a system upgrade everything is fine, of course. Given that...I suppose you could argue rpmdeplint's behavior here is correct, and actually, compiler-rt18 should obsolete or conflict with compiler-rt < 19. It seems it currently conflicts with |
As explained in issue #20, when checking for conflicts, it's not enough to skip only existing packages with the same name as the one they are being checked against. We should skip all existing packages that the set of packages being tested would replace.
Fortunately, we already have
_select_obsoleted_byto do this exact job, so let's just use it here.We keep the existing 'skip if the names are the same' check to avoid generating confusing results if the update under test contains a package with the same name as an existing package but with a lower EVR. This is wrong, but we should leave it to be caught by other checks; handling it here would give a rather confusing failure about file conflicts between the two packages, which the packager might not understand.