Skip to content
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

Open
jwrdegoede opened this issue Jan 29, 2017 · 4 comments
Labels
RFE Requests for Enhancement

Comments

@jwrdegoede
Copy link

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.

@AdamWill
Copy link
Contributor

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, python-wikitcms and fedfind. I make changes which require me to update both packages together, so I submit an update with both packages in it. Then I start waiting to be able to push it stable - 7 days for Fedora, 14 for EPEL (since I never get enough karma to push otherwise). But when it's been there for, like, 6 or 13 days, I realize I want to make another change to python-wikitcms. But I don't want to lose my 6 or 13 days of 'update waiting time credit'! So I don't edit the existing update, or obsolete it, I just create a new update with only python-wikitcms in it. As long as I remember to push the 2-package update before I push the python-wikitcms-only update, this is fine, and I do want to be able to do that.

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...

@bowlofeggs
Copy link
Contributor

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.

@bowlofeggs bowlofeggs added the RFE Requests for Enhancement label Feb 1, 2017
@bowlofeggs
Copy link
Contributor

For the record, there are a few other issues around obsoletion in Bodhi that might be relevant or even duplicates of this one. Two that came to my mind were:

#512
#145

@pmatilai
Copy link

pmatilai commented Nov 6, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFE Requests for Enhancement
Projects
None yet
Development

No branches or pull requests

4 participants