Improvements to the auto-obsoletion behavior. #33
Conversation
|
We hit an issue today that this feature would fix. https://admin.fedoraproject.org/updates/FEDORA-2014-1874/abrt-2.1.12-1.fc19,libreport-2.1.12-1.fc19,abrt-java-connector-1.0.8-1.fc19 Did not get auto-obsoleted because a newer update was submitted that contained abrt and libreport, but not abrt-java-connector. The auto-obsoletion logic in bodhi would then skip obsoleting it because the packages didnt match. |
This allows new updates to obsolete any updates containing older versions, along with builds for packages not present in the new update. These non-obsolete builds are then inherited into the new update.
This reverts commit 552c05a until we can figure out how to get it working on EPEL6.
|
This change is sorely needed. However, after staring at this for 45 minutes, I think I got what it's doing, and it seems alright... 😕 What keeps confusing me is that a build can theoretically have multiple updates in the model, so you're constantly iterating over the updates of a given build. However, we're in fact mandating that one build can be in only one update (through obsoletion or errors), and so those for loops ( I'll see if I can try it out on my own instance. |
|
Yeah, you're right about that. At the time iterating over the |
|
I'm going to merge this at some point in the near future unless someone objects :D |
|
@lmacken What is "the near future"? |
|
Closing this in favor of #145. |
This allows new updates to obsolete any testing updates containing older versions, along with builds for packages not present in the new update. These non-obsolete builds are then inherited into the new update just like the bugs and notes.