Updates should be able to relate to other updates

[bowlofeggs]

There may be some use cases where it makes sense to have an update depend on another update.

For example, some of Fedora's content bundles other bits of Fedora's content. Consider containers: we have a base layer image, and we have second layer images and even some third layer images. When we perform mass container rebuilds, we won't have a good way to ensure that the base layer is tagged stable when one of its dependent layers goes stable, other than to put them in the same update. It would be undesirable to have one update for each mass rebuild, as karma then becomes less meaningful (which container did the user test?)

Another example might be the go language, which bundles dependencies and thus has a similar problem.

There are a couple ideas I've considered for solving this problem:

1. Updates could have the ability to depend on other updates. With this model, a dependent update could not be stabilized until the update it depends on is stabilized. This way, the "parent" update can be released without the "child", but the child cannot be release without the parent.
2. We could create an update group model. With this model, we could start to mash update groups "all or none", meaning that none of the updates in the group are released until they are all marked stable.

There may be other ways to solve this problem, so feel free to propose your own ideas (as always).

[mohanboddu]

I prefer 1st option, since if something went wrong with child update/layered image we will still be able to push parent update/base image. Where as in 2nd option one has to wait until the child update/layered image is fixed, which can be annoying.

[bowlofeggs]

@mohanboddu Yeah I think I agree. Thanks!

[jasontibbitts]

Note that this may be related to #2191, which I just filed.

[gnu-andrew]

Having something like the 1st option is very much overdue.

We've just had an issue where our OpenJDK update depended on a tzdata update (2022e) that was still in testing for some releases (F35 & F37). 2022e was out in F36 and rawhide, and on track to go out in a few days on the other two, so, at the time of submitting the update, it seemed fine to keep all four in sync and have us depend on 2022e.

However, the only way we can express this at present is in the text for users (e.g. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d0ed59bee7) so Bodhi itself isn't aware of the dependency.

Lo and behold, tzdata gets updated to 2022f, which derails the 2022e update which was on the verge of going out. Bodhi happily ships on the JDK update anyway and users experience dependency breakage, which won't be resolved until 2022f trickles out.

This could have been avoided if the JDK update could have formally depended on the tzdata update and only been pushed to stable if the tzdata update was in stable.