As part of the AutoQA test suite we have an Upgradepath test that ensures that package dependencies won’t be broken when upgrading from one Fedora release to a higher one. There is often some confusion among package maintainers why it fails so often when they propose an update for several Fedora release at once. I’d like to explain.
Here’s an example failure log:
======================================== wordpress-3.1.2-1.fc13 into dist-f13-updates ======================================== [ OK ] dist-f13 Latest package: wordpress-2.8.6-2.fc13 [FAIL] dist-f14 + dist-f14-updates Latest package: wordpress-3.1-1.fc14 Error: Proposed package must be less than or equal to the latest package [FAIL] dist-f15 + dist-f15-updates Latest package: wordpress-3.1-1.fc15 Error: Proposed package must be less than or equal to the latest package [ OK ] dist-f16 Latest package: wordpress-3.1.2-1.fc16 RESULT: FAILED
The proposed update for F13-updates fails upgradepath, because that package exists in F14(+updates) and F15(+updates) only in lower versions. You wouldn’t be able to upgrade from F13 to F14 correctly if the proposed update landed.
But here’s the tricky part – wordpress maintainer proposed this update also for F14-updates and F15-updates, not just F13. And the obvious question now is:
Why does upgradepath fail for F13, when the same update for F14 and F15 is already proposed?
The answer is:
Because we can’t be sure all of them are going to be pushed at the same time.
Various things might happen. Let’s imagine RelEng team will push the update for F13, but will reject the same update for F14. Or the F14 update will get unpushed in the meantime. Or something else.
This calls for some kind of transactional behavior: “All these updates for F13, F14 and F15 must be pushed at the same time. Or just F15 update can be pushed. But no other way.” Unfortunately we can’t do this, yet. Until we can, there is only one way how to be perfectly sure that upgradepath constraint is fulfilled, and that means the updates for higher Fedora releases must land in the repos first.
Nevertheless we strive to be more user-friendly, especially concerning log readability and test understandability. It’s our current top priority. We will improve the logs to contain helpful information as much as we can, to explain this issue better. Very soon every test will have its own documentation wiki page. Upgradepath documentation is already available, please have a look at AutoQA test/Upgradepath. And we will continue to improve that.
If you have some suggestions, please send them to autoqa-devel. Thanks.
Kparal's Fedora Blog 