Day: April 18, 2011

AutoQA – upgradepath vs updates to multiple Fedora releases


If you are a package maintainer, you probably need sometimes to push the same update to several Fedora releases. But upgradepath may report failures for some of your updates. What’s wrong?

Let’s imagine this situation:

Packages in stable updates:

  • foo-1.0-1.fc14
  • foo-1.0-1.fc15
  • foo-1.0-1.fc16
Now you decide to propose these updates:
  • foo-1.1-1.fc14
  • foo-1.1-1.fc15
  • foo-1.1-1.fc16
The result may be following:
  • foo-1.1-1.fc14 – upgradepath will FAIL because Fedora 15 still contains just foo-1.0
  • foo-1.1-1.fc15 – upgradepath will FAIL because Fedora 16 still contains just foo-1.0
  • foo-1.1-1.fc16 – upgradepath will PASS since there is no Fedora 17
The effective result is that you have to first push the update to the highest Fedora version (Rawhide) and only then you will see upgradepath produce PASS result for the update going to the previous version of Fedora.

You probably guessed that the reason for this behavior is that upgradepath considers every update individually, not as “set of updates”. In the future we would like to improve that and prepare these “set of updates safe to push” for RelEng team. But currently the aforementioned behavior was the one that was quick and easy to do. We plan many improvements in the future.

What are the implications?
  1. If you want to have certainty that your update doesn’t break upgradepath constraint, push to the highest Fedora release first and then consequently to lower ones. Or at least inspect upgradepath logs if there is really no other issue with your update than this one.
  2. If you want to push update for a single Fedora release, you don’t have to push for the others. Read Minor release bumps for old branches.
  3. Upgradepath is re-evaluated for all pending updates regularly (and very often). If your update received a FAILED result, correct the situation and in a short time you should receive PASS result. If you update still fails, we will inform you only once in 3 days to avoid spamming.
  4. Don’t forget that AutoQA results are purely informative, they do not block your actions.