AutoQA tests/Upgradepath

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
m (typo)
(explain OK sections)
Line 27: Line 27:
 
RESULT: FAILED
 
RESULT: FAILED
 
</pre>
 
</pre>
 +
 +
The '''OK''' sections denote repositories where upgradepath constraint would be fulfilled after pushing the proposed update. For example it would be possible to upgrade from <code>dist-f13</code>, because it contains lower version of <code>gthumb</code> package. And it would be also possible to upgrade to <code>dist-f16</code>, because it contains higher version of <code>gthumb</code> package. Similarly for other repositories marked as '''OK'''.
  
 
If you look closely at the '''FAIL''' section, you'll see, that union of <code>dist-f15</code> and <code>dist-f15-updates</code> repositories contains only <code>gthumb-2.12.2-2.fc15</code>, which is lower version than currently proposed <code>gthumb-2.12.3-1.fc14</code> for <code>dist-f14-updates</code>. It fails because you wouldn't be able upgrade from F14 to F15 correctly if the proposed update had been pushed.
 
If you look closely at the '''FAIL''' section, you'll see, that union of <code>dist-f15</code> and <code>dist-f15-updates</code> repositories contains only <code>gthumb-2.12.2-2.fc15</code>, which is lower version than currently proposed <code>gthumb-2.12.3-1.fc14</code> for <code>dist-f14-updates</code>. It fails because you wouldn't be able upgrade from F14 to F15 correctly if the proposed update had been pushed.
  
In the example above, the package maintainer may have proposed the same update (<code>gthumb-2.12.3-1</code>) for <code>dist-f15-updates</code> at the same time. If both updates were pushed simultaneously, the upgradepath constraint would be satisfied. Unfortunately AutoQA cannot enforce that in the moment and therefore the update for <code>dist-f14-updates</code> will continue to fail the test until the update for <code>dist-f15-updates</code> is pushed.
+
In the example above, the package maintainer may have proposed the same update (<code>gthumb-2.12.3-1</code>) also for <code>dist-f15-updates</code> at the same time. If both updates were pushed simultaneously, the upgradepath constraint would be satisfied. Unfortunately AutoQA cannot enforce that in the moment and therefore the update for <code>dist-f14-updates</code> will continue to fail the test until the update for <code>dist-f15-updates</code> is pushed.
  
 
== Upgradepath test algorithm ==
 
== Upgradepath test algorithm ==

Revision as of 08:36, 11 May 2011

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 wants 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.

AutoQA executes this test for any update that is proposed in Bodhi and reports the result using Bodhi comments at the update page.

Note.png
Does not apply for updates-testing
Upgradepath constraint is currently checked for main and stable updates repositories. It is not checked for updates-testing repository.

Contents

Understanding failures

This is a sample output of the upgradepath test, where gthumb-2.12.3-1.fc14 was requested to be pushed to dist-f14-updates repository:

========================================
gthumb-2.12.3-1.fc14 into dist-f14-updates
========================================
[ OK ] dist-f13
	Latest package: gthumb-2.11.3-1.fc13
[ OK ] dist-f13-updates
	Latest package: gthumb-2.12.2-1.fc13
[ OK ] dist-f14
	Latest package: gthumb-2.12.0-1.fc14
[FAIL] dist-f15 + dist-f15-updates
	Latest package: gthumb-2.12.2-2.fc15
	Error: Proposed package must be less than or equal to the latest package
[ OK ] dist-f16
	Latest package: gthumb-2.12.3-2.fc16
RESULT: FAILED

The OK sections denote repositories where upgradepath constraint would be fulfilled after pushing the proposed update. For example it would be possible to upgrade from dist-f13, because it contains lower version of gthumb package. And it would be also possible to upgrade to dist-f16, because it contains higher version of gthumb package. Similarly for other repositories marked as OK.

If you look closely at the FAIL section, you'll see, that union of dist-f15 and dist-f15-updates repositories contains only gthumb-2.12.2-2.fc15, which is lower version than currently proposed gthumb-2.12.3-1.fc14 for dist-f14-updates. It fails because you wouldn't be able upgrade from F14 to F15 correctly if the proposed update had been pushed.

In the example above, the package maintainer may have proposed the same update (gthumb-2.12.3-1) also for dist-f15-updates at the same time. If both updates were pushed simultaneously, the upgradepath constraint would be satisfied. Unfortunately AutoQA cannot enforce that in the moment and therefore the update for dist-f14-updates will continue to fail the test until the update for dist-f15-updates is pushed.

Upgradepath test algorithm

The formal description of the 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

Fixing the failures

The general guidelines are these:

  • Push first to the highest Fedora release and only then to a lower one.
    You can of course propose your update for all supported Fedora releases at once, but upgradepath test will not pass for any Fedora release until it has been pushed to all higher Fedora releases. See longer explanation.
  • Consult packaging guidelines when in doubt how package build versions are compared.
    See especially the Naming guidelines.
  • If you want to push a fix for an older Fedora but not for a newer one, do a proper minor release bump.
    Read Minor release bumps for old branches to learn more.

Further help

If you still don't understand why your update failed the test, or if you think there's something wrong in our test or its documentation, or if you have any other suggestions, please contact us.