Dependencies on Bodhi Updates

Adam Williamson awilliam at
Tue Mar 27 18:30:56 UTC 2012

On Mon, 2012-03-26 at 15:53 -0400, Stephen Gallagher wrote:

> So I really see two options for improving these situations:
> 1) I opened this ticket two
> months ago (to silence). The idea would be to add the ability for bodhi
> updates to mark other updates as a dependency, so that in the example
> above, Firefox could have been marked as ready for stable, but not
> pushed until the nss update was also marked as ready for stable. This to
> me seems like the best long-term solution. I'd also like to mention that
> Ubuntu's Launchpad system has this capability.

> 2) We could continue on the "single update for multiple packages"
> approach, but revamp the karma system so that each SRPM gets its own
> karma, rather than the update as a whole. Then, the whole update would
> not be pushed via autokarma until all of the dependent packages had
> sufficient karma (or the owner of the update could push them after the
> stable wait period, of course).

I think either of these would be an improvement. Both are likely Bodhi
2.0-dependent, though. As I understand the Bodhi 2 design, it would
certainly be capable of at least the second (as it's intended to make
feedback a much more customizable and granular thing).

I think we'd need to make the second more optional than you suggest,
though. For instance, when the desktop team pushes a 'GNOME 3.4' update
with 30 packages in it, they really want that update to be tested as a
whole - broadly they just want people to install all the updates, boot
into GNOME, and make sure stuff mostly works. They probably don't want
the entire update blocked if there's a typo in the Help file for one of
the games, or something.

So I think there are cases where an update owner would not want to
require the threshold karma on every single sub-package in an update.
With that caveat, though, I do like the ideas.
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | adamwfedora

More information about the devel mailing list