#123: rpmguard: check upgrade paths between releases ----------------------+----------------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Component: tests | Version: 1.0 Keywords: rpmguard | ----------------------+----------------------------------------------------- (As pointed out by spot on the devel list: http://lists.fedoraproject.org/pipermail/devel/2010-March/131746.html)
We should be emitting warning/error messages if the new package(s) have a higher ENVR than the currently-released package(s) in any newer release.
For example, right now a new F11 package should be checked against the corresponding package(s) in the current F12, branched F13, and rawhide repos.
This involves a lot of extra repos and metadata, though. It's not a trivial thing to add.
#123: rpmguard: check upgrade paths between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Component: tests | Version: 1.0 Resolution: | Keywords: rpmguard ---------------------+------------------------------------------------------ Comment (by kparal):
I agree, this a very important test. But I don't think it should be the task of rpmguard, the rpmguard just prints differences between two packages. I think it would be best to create a separate test just for upgrade path testing.
I can volunteer to do that, it can be interesting. I just want to stress I believe it should be a new test.
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by wwoods):
* keywords: rpmguard => * summary: rpmguard: check upgrade paths between releases => New test: check upgrade paths (etc) between releases
Comment:
Yeah, that sounds reasonable. Removing rpmguard keywords.
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by jlaska):
* milestone: => Package update tests
Comment:
Re-assigning to 'package update tests' milestone
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by jlaska):
skvidal drafted a script to compare packages in F12 and F13 and hilight the F13 packages that are older than F12 packages.
http://skvidal.fedorapeople.org/misc/newer_pkgs_in_old_repos.py
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by skvidal):
This is not a good script to build from but the idea is easy enough if you're doing it for comparing sets of repos.
However, if you're just doing to compare 1 pkg then you'd want to do:
1. return a list of all the pkgs matching name of the pkg in question. 2. sort the list by EVR (which is just sort for yum pkg objects) 3. take the highest one and compare it to your pkg. If it is not less than or equal to your pkg, then you have an issue to flag.
If y'all can tell me where the 'other' pkgs are and how I can query them I can probably put this together for you.
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by jlaska):
Replying to [comment:5 skvidal]:
This is not a good script to build from but the idea is easy enough if
you're doing it for comparing sets of repos.
However, if you're just doing to compare 1 pkg then you'd want to do:
- return a list of all the pkgs matching name of the pkg in question.
- sort the list by EVR (which is just sort for yum pkg objects)
- take the highest one and compare it to your pkg. If it is not less
than or equal to your pkg, then you have an issue to flag.
If y'all can tell me where the 'other' pkgs are and how I can query them
I can probably put this together for you.
Apologies for delay. I *think* what you might use is autoqa.koji_utils (see [http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=lib/python/koji_utils...]).
Perhaps something like ...
{{{ import autoqa.koji_utils koji = autoqa.koji_utils.SimpleKojiClientSession() envr="lftp-4.0.5-2.fc13" name="lftp"
print "Proposed update - %s" % envr print "Available in N-1 - %s" % (koji.list_previous_release(name, "dist-f12-updates-candidate")['nvr'],) print "Available in N-2 - %s" % (koji.list_previous_release(name, "dist-f11-updates-candidate")['nvr'],) }}}
What's missing ... * using autoqa.koji_utils.compareNVR() to determine if a previously released verion is newer. * something build-into autoqa.koji_utils that understands which tags to use when looking for older packages?
Just some thoughts. Is this what you were looking for?
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by jlaska):
Attached is a sample script I played with to get something working. I'm not 100% sure I'm using the correct method to determine the previous Fedora releases for the provided update. But in my testing, this seems to work well enough. It returns '1' upon failure.
Some sample calls included below.
* Checking if ''ypbind-1.31-3.fc13'' has a sane upgrade path if it were to be released in ''dist-f14-updates-candidate'' {{{ # python upgrade-path.py -n ypbind-1.31-3.fc13 -t dist-f14-updates- candidate Checking proposed update for ypbind-1.31-3.fc13 tagged in dist-f14 -updates-candidate Available in dist-f14-updates-candidate - ypbind-1.31-4.fc14 (FAIL) Available in dist-f13-updates-candidate - ypbind-1.31-2.fc13 (OK) Available in dist-f12-updates-candidate - ypbind-1.20.4-23.fc12 (OK) }}}
* Checking if ''ypbind-1.31-3.fc13'' has a sane upgrade path if it were to be released in ''dist-f13-updates-candidate'' {{{ # python upgrade-path.py -n ypbind-1.31-3.fc13 -t dist-f13-updates- candidate Checking proposed update for ypbind-1.31-3.fc13 tagged in dist-f13 -updates-candidate Available in dist-f13-updates-candidate - ypbind-1.31-2.fc13 (OK) Available in dist-f12-updates-candidate - ypbind-1.20.4-23.fc12 (OK) Available in dist-f11-updates-candidate - ypbind-1.20.4-19.fc11 (OK) }}}
* Checking if ''ypbind-1.31-3.fc13'' has a sane upgrade path (autodetect current release) {{{ # python upgrade-path.py -n ypbind-1.31-3.fc13 Checking proposed update for ypbind-1.31-3.fc13 tagged in dist-f13 -updates-candidate Available in dist-f13-updates-candidate - ypbind-1.31-2.fc13 (OK) Available in dist-f12-updates-candidate - ypbind-1.20.4-23.fc12 (OK) Available in dist-f11-updates-candidate - ypbind-1.20.4-19.fc11 (OK) }}}
I'm sure it can be improved, suggestions welcome.
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by till):
* cc: till (added)
Comment:
According to the examples, there is only a backward check but no forward check happening. E.g. if ypbind-1.31-3.fc13 should be added to dist-f13 -updates-candidate, it needs to be checked, whether all new releases have a higher NEVR, i.e. dist-f14-updates-candidate needs to be checked. The other way round is afaics not that important, because if you guarantee that a package all packages in F(N+1) have a higher NEVR than the new package in F(N), then no do not need to check F(N-1), assuming that EVR will always increase.
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by jlaska):
Replying to [comment:8 till]:
According to the examples, there is only a backward check but no forward
check happening. E.g. if ypbind-1.31-3.fc13 should be added to dist-f13 -updates-candidate, it needs to be checked, whether all new releases have a higher NEVR, i.e. dist-f14-updates-candidate needs to be checked. The other way round is afaics not that important, because if you guarantee that a package all packages in F(N+1) have a higher NEVR than the new package in F(N), then no do not need to check F(N-1), assuming that EVR will always increase.
Good suggestion. Certainly worth exploring that option, and a fairly trivial code change with the example posted so far.
You suggestion brings up a good point. With either approach, are there any undocumented package update order requirements being implicitly enforced by this test?
With the approach you suggest, packages must be released starting with the newest Fedora release, and then for each applicable older release. For example: 1. devel (rawhide) 2. Fedora + 1 (branched) -- ''if desired'' 3. Fedora (current) -- ''if desired'' 4. Fedora - 1 (previous) -- ''if desired'' 5. Fedora - 2 (previous+1) -- ''if desired''
With the other approach, packages must be released starting with the oldest desired Fedora release. For example: 1. Fedora - 2 (previous+1) -- ''if desired'' 2. Fedora - 1 (previous) -- ''if desired'' 3. Fedora (current) -- ''if desired'' 4. Fedora + 1 (branched) -- ''if desired'' 5. devel (rawhide)
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by till):
Replying to [comment:9 jlaska]:
You suggestion brings up a good point. With either approach, are there
any undocumented package update order requirements being implicitly enforced by this test?
Afaik the upgrade path is only about having the newer NEVR first in the newer Fedora releases. The afaik unanswered question is still from which package collection to which package collection this needs to be ensured. E.g. is it enough to have it from FN stable to FN+1 updates-candidate? Iirc from the FESCo ticket, there is no decision about what is desired here, but only a goal to check out what is (currently?) technically possible to ensure and then use this.
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package update tests Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by robatino):
* cc: robatino (added)
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: vaschenb Type: task | Status: new Priority: major | Milestone: Package Update Acceptance Test Plan Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by kparal):
* owner: => vaschenb
Comment:
Vojta is currently working on this test.
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: vaschenb Type: task | Status: new Priority: major | Milestone: Package Update Acceptance Test Plan Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by jlaska):
I believe this is now in master. Vojta, can you confirm? If so, feel free to close this ticket. Thanks!
#123: New test: check upgrade paths (etc) between releases ---------------------+------------------------------------------------------ Reporter: wwoods | Owner: vaschenb Type: task | Status: closed Priority: major | Milestone: Package Update Acceptance Test Plan Component: tests | Version: 1.0 Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by kparal):
* status: new => closed * resolution: => fixed
Comment:
Yes, this is now in master.
autoqa-devel@lists.fedorahosted.org
-
fedora-badges