#497 [glib2] glib2-devel installation error: file /usr/share/glib-2.0/codegen/__pycache__/codegen_docbook.cpython-310.pyc conflicts between attempted installs of glib2-devel-2.70.0-3.fc35.i686 and glib2-devel-2.70.0-3.fc35.x86_64 | rhbz#2008912
Closed by blockerbot. Opened by blockerbot.

Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2008912 **
Information from BlockerBugs App:
2008912

Current vote summary

Commented but haven't voted yet: zbyszek

The votes have been last counted at 2021-10-06 17:44 UTC and the last processed comment was #comment-756701

To learn how to vote, see:
https://pagure.io/fedora-qa/blocker-review
A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)


FinalBlocker -1
FinalFE +1

Reversing my blocker vote based on the discussion that follows.

FinalBlocker -1
FinalFE -1

The proposed release criterion does not apply at all, since multilib packages are not installed by default.

And it also does not matter whether the fix is present on the GA images or not -- to avoid this bug, it should be sufficient for an update to be available in the updates repo -- so there's also no need for a freeze exception.

FinalFE +1

And it also does not matter whether the fix is present on the GA images or not -- to avoid this bug, it should be sufficient for an update to be available in the updates repo -- so there's also no need for a freeze exception.

Actually that is wrong, sorry, because this is annoying for anyone using multilib who is trying to upgrade to F35 prior to the final release. So a freeze exception does make sense.

FinalBlocker -1
FinalFE +1

This doesn't break the criterion, I don't think, as -devel packages are not in any release-blocking default package set I'm aware of. But an FE to fix upgrades during freeze would be good.

Yeah, FE is probably correcter.

That said, I think it'd make sense to revisit the criteria to require all packages to be upgradeable. The file conflict that this bug is about is detected by dnf in the transaction check phase, i.e. after all packages have been downloaded. This means that dnf system-upgrade will fail very late, making people rather unhappy. And file conflicts is something that we can easily detect automatically. So I think it'd make sense to add a criterion that any packages that could be installed together before can be upgraded, period. Something to discuss after F35 has been released.

FinalBlocker -1
FinalFE +1

That said, I think it'd make sense to revisit the criteria to require all packages to be upgradeable.

That is impossible. We have hundreds of FTI packages with each release.

FinalBlocker -1
FinalFE +1

yeah, that would be a requirement a long way too far at present, unfortunately.

AGREED RejectedFinalBlocker AcceptedFinalFE

The following votes have been closed:

Metadata Update from @blockerbot:
- Issue status updated to: Closed (was: Open)

Release F35 is no longer tracked by BlockerBugs, closing this ticket.

Log in to comment on this ticket.

Metadata