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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
