Upgradepath is a constraint that is not formally described anywhere but it is generally understood as the ability to upgrade from Fedora release N to Fedora release N+1.
In other words no package dependencies may break when the user want to upgrade his/her Fedora. That is achieved by requiring the higher Fedora release to contain at least the same or higher package build versions (in N-V-R sense) than the lower Fedora release.
This is a sample output of the upgradepath test, where
selinux-policy-3.9.16-21.fc15 was requested to be pushed to
======================================== selinux-policy-3.9.16-21.fc15 into dist-f15-updates ======================================== [ OK ] dist-f13 Latest package: selinux-policy-3.7.19-10.fc13 [ OK ] dist-f13-updates Latest package: selinux-policy-3.7.19-101.fc13 [ OK ] dist-f14 Latest package: selinux-policy-3.9.7-3.fc14 [ OK ] dist-f14-updates Latest package: selinux-policy-3.9.7-40.fc14 [ OK ] dist-f15 Latest package: selinux-policy-3.9.16-18.fc15 [FAIL] dist-f16 Latest package: selinux-policy-3.9.16-15.fc16 Error: Proposed package must be less than or equal to the latest package RESULT: FAILED
If you look closely at the FAIL section, you'll see, that
dist-f16 (current Rawhide) contains only
selinux-policy-3.9.16-15.fc16, which is lower version than currently proposed
f15-updates. It fails because you wouldn't be able upgrade from F15 to F16 correctly if the proposed update had been pushed.
Upgradepath test algorithm
The formal description of algorithm AutoQA uses for checking upgradepath constraint is here:
== Pushing to main repository == Pushing PKG to F(N)-main means: 1. PKG in F(lower)-main <= PKG to push 2. PKG in F(higher)-main >= PKG to push == Pushing to updates repository == Pushing PKG to F(N)-updates means: 1. PKG in F(lower)-main <= PKG to push 2. PKG in F(lower)-updates <= PKG to push 3. PKG in F(higher)-main union F(higher)-updates => PKG to push Note: If PKG doesn't exist in REPO, it also satisfies any condition