-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto obsoleting of non-stable updates with older-versions on same branch is broken #1254
Comments
I agree this is a problem, but I kinda disagree with the proposed solution. I often find myself in this situation. I have two packages, one with a dependency on the other - say, As @bowlofeggs says this is a really tricky question. I was about to suggest 'ok, so Bodhi should just disallow push of the one-package update until the two-package update had been pushed'. But then I thought about it a bit more and there are probably cases where pushing the single-package update would actually be OK...it's difficult. So maybe (we just talked about this) the best thing Bodhi can do is just pop up some kind of warning when you try to push an update and this sort of situation exists, and give you references to the existing updates and let you figure it out... |
Thanks for the comment @AdamWill! I agree - it will be difficult to automate this and so we may have to rely on human judgement. I'll mark this as an RFE for adding a message to the developer that there is another update that the developer should consider and decide what to do. |
People make mistakes, forget and sometimes are just plain unaware of other peoples actions (such as a pending update), and silently auto-obsoleting an update (of different type, submitted by another person and all) that might be deep into testing without a single question asked is just terrible. Please bump up the priority, we just essentially lost an important security update because of this. |
From: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/H7YTJCEQ2CRRUEN6WZDGJVZOYVTDIQVE/
The real problem is that either the new libglvnd enabled mesa should not be in updates-stable and thus not in the buildroot; or both the new libglvnd enabled mesa and the new libglvnd should be in updates-stable. What happened is I created an update in bodhi for libglvnd-0.2.999-7.gitdc16f8c.fc25 and mesa-13.0.3-3.fc25. Then airlied did an unrelated bug-fix to mesa and created an update in bodhi for mesa-13.0.3-4.fc25. This update did not obsolete my previous update, did not inherit it bugs and did not inherit the libglvnd package which was only in my update. When I noticed things both updates were in perpetual locked state, when they were finally unlocked airlied's update got auto-pushed to stable because of karma (I had auto-karma disabled on mine), so now we have a mesa depending on the latest libglvnd in updates-stable, without the latest libglvnd. When I tried to also push my update to stable, I could not as bodhi complained there was a newer mesa already in stable, so I had to remove mesa from my update (why does it detect conflicts like this on push and not when someone creates a conflicting update?), loosing all karma??? and now it is pending for testing. Frankly I blame this whole mess on bodhi, it should not allow creating updates which partly obsolete other updates, there likely is a good reason the partly obsoleted update bundled multiple packages in one update; or it should allow it and then simply add all non obsoleted packages from the obsoleted update to the new update and obsolete the old one.
The text was updated successfully, but these errors were encountered: