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

+

+

{{admon/note|Does not apply for updates-testing|Upgradepath constraint is currently checked for main and stable updates repositories. It is [https://fedorahosted.org/autoqa/ticket/231 not checked] for updates-testing repository.}}

+

+

== Understanding failures ==

+

This is a sample output of the upgradepath test, where <code>selinux-policy-3.9.16-21.fc15</code> was requested to be pushed to <code>f15-updates</code> repository:

+

+

<pre>

+

========================================

+

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

+

</pre>

+

+

If you look closely at the '''FAIL''' section, you'll see, that <code>dist-f16</code> (current [[Rawhide]]) contains only <code>selinux-policy-3.9.16-15.fc16</code>, which is lower version than currently proposed <code>selinux-policy-3.9.16-21.fc15</code> for <code>f15-updates</code>. 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:

+

<pre>

+

== 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

+

</pre>

+

+

== Fixing the failures ==

+

+

+

[[Category:AutoQA tests]]

Revision as of 09:48, 5 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 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.

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

Understanding failures

This is a sample output of the upgradepath test, where selinux-policy-3.9.16-21.fc15 was requested to be pushed to f15-updates repository:

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 selinux-policy-3.9.16-21.fc15 for 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:

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.