package dependencies in Bodhi

[Adam Williamson]

On Thu, 2012-03-15 at 10:13 -0400, Kamil Paral wrote:
> We have found some problems in our AutoQA tests when updates proposed
> in Bodhi change while we're testing them. We discovered it using this
> extreme update example:
> 
> http://bit.ly/xxwTU6
> 
> It was modified roughly 20 times during 2 days. We tried to fix our
> tests, but some questions remain. I'd like to understand more of this
> Bodhi process and why it might be necessary to modify your update so
> much.
> 
> Example: I am a maintainer of packages X and Y, X depends on an exact
> version of Y. Someone else is a maintainer of package Z, Z depends on
> an exact version of X. A bug in Y is fixed, it's rebuilt, therefore I
> have to rebuild X as well. Z is now broken (needs to be rebuilt
> against newer X).
> 
> 1. When pushing newer X and Y to Bodhi, am I reminded somehow that Z
> needs to be rebuilt and pushed as part of this update as well? 

No.

> Or just our depcheck test tells you that, nothing before that?

Yes.

> 2. Who should be rebuilding and pushing Z, me or its maintainer?

This is...somewhat unclear. Sometimes people who maintain particularly
popular libraries are granted provenpackager status so they can do
rebuilds of the dependencies when they do ABI changes, which implies the
former. The guidelines do not specifically state whose responsibility it
is, and different bits of the text seem to imply both ways:

https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages

"In Rawhide, updates to packages may cause other packages to have broken
dependencies. Maintainers will be alerted when this happens, and should
work to rebuild their packages with all due haste" implies that it's the
maintainer of the dependent package's responsibility to do this (at
least as it relates to Rawhide), but "If your package upgrade breaks
other packages in Rawhide, you should try to help fix the packages
affected. For example, if you're a provenpackager, queue the rebuilds
yourself" weakly states the opposite. It's really not particularly
clear. And the text was obviously written with Rawhide in mind, not
Bodhi-handled releases. The updates policy does refer to ABI/API
breakage a little. It says that, during pre-Beta times, "Maintainers
SHOULD (not enforced): Avoid ABI/API changes where possible. If
unavoidable, should coordinate a side tag to rebuild packages in or a
mass build/update" - implying that it's the provider packager's
responsibility to "coordinate" the rebuilds. That's the most applicable
text for *this specific case* you cite: the desktop team really should
have lined their ducks up a bit better ahead of time.

>  Ideally it should be part of the same Bodhi update, right?

Yes. In fact, I would state this more strongly: *no* update should, if
applied in isolation, result in dependency problems. Any update which
causes dependency changes must include all the packages necessary to
ensure dependencies stay consistent.

The updates policy is not particularly solid on this. For pre-Beta
times, it has the text mentioned two paragraphs above. For Rawhide
times, it says "A week in advance, notify maintainers who depend on
their package to rebuild when there are abi/api changes that require
rebuilds in other packages or offer to do these rebuilds for them". But
for post-Beta and post-release times, it says only "Avoid Major version
updates, ABI breakage or API changes if at all possible"; it does not
set out any required practices or responsibilities for when an ABI/API
change *does* happen.

> 3. What might be the reason to add new and new packages to my proposed
> update, like we've seen in the example linked above? What use cases am
> I missing apart from broken dependencies?

Dependencies are by far the most common reason for this that I can think
of - either explicitly stated dependencies, or 'softer' ones (like when
an update is submitted and a commenter points out that it has
implications for some other package which are not expressed by an
explicit dependency).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net