Bug 208850
Summary: | RHN does not treat no epoch as epoch = 0 | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Network | Reporter: | James Bowes <jbowes> | ||||
Component: | RHN/Other | Assignee: | Mike McCune <mmccune> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | wes hayutin <whayutin> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rhn500 | CC: | bkearney, cperry, jpazdziora, rhn-bugs | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | sat500 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-06-26 03:02:40 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 212614 | ||||||
Bug Blocks: | 173427, 210233, 212240, 212244 | ||||||
Attachments: |
|
Description
James Bowes
2006-10-02 13:09:53 UTC
So, is this bug client-side or server-side? I'm inclined to believe it is server-side. jslagle determined that the plsql vercmp is doing the wrong thing. And the java code in ProfileManager.vercmp will need to change to coincide with the pl/sql change. jesusr, can you state whether the java code got fixed? *** Bug 212244 has been marked as a duplicate of this bug. *** The java code has NOT been fixed. If the plsql has been fixed, we can go ahead and fix it in the java code. one area of concern... is this rpm as of a certain point in time? I.e., rhel4+? If so, will server-side all of a sudden start doing the wrong thing for as2.1 & rhel3? Hopefully, this isn't any kind of issue and I'm just being supremely paranoid :) Not a server side blocker. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. * PLSQL and Java code fixed. Not sure how to test this thing. Possibly one of the backend guys might be able to suggest a good test plan. (In reply to comment #8) > Not a server side blocker. Uh, this is entirely server-side. (In reply to comment #10) > * PLSQL and Java code fixed. > > Not sure how to test this thing. Possibly one of the backend guys might be able > to suggest a good test plan. Yeah, what you want to look at is something like: * Hop onto a rhel 5 client. * `yum install` a bunch of different rpms. Ideally, some of them will be updates to already installed rpms. * Check RHN and look at your package profile. Make sure that there is only one package installed for the updated one (not the old and the new), and that all the packages that have been installed are clickable, and take you to an actual web page. * This bug also showed up sometimes with RHN showing that your system needed updates, when the package it said you needed to update was already at a later version, due to some differences in their epochs. Created attachment 148119 [details]
ss of problem
So to be sure I think I need to rebuild a rhel 5 server... and run through the recreate... I will do that once I get permission... However... yum/rpm and rhn are reporting the same packages twice... so I'm sending this back to dev to take a look to see if that should EVER happen... [root@bperkins-64 ~]# rpm -qa | grep aspell aspell-0.60.3-7.1 aspell-en-6.0-2.1 aspell-0.60.3-7.1 [root@bperkins-64 ~]# rpm -qa | grep atk atk-1.12.2-1.fc6 atk-1.12.2-1.fc6 The above screen shot displays the same packages twice... Clearing the RHEL flag. This is a Hosted 500 issue. (In reply to comment #14) > The above screen shot displays the same packages twice... Those are probably 64bit and 32bit versions of the packages. *** Bug 212240 has been marked as a duplicate of this bug. *** *** Bug 212614 has been marked as a duplicate of this bug. *** Re comment 14: put the following line to your .rpmmacros to make sure they are not multilibs: %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} verified by installing a back dated version of screen.. on rhel 5 updating using rhn.. only one version listed on client... [root@fjs-0-10 ~]# rpm -qa | grep screen screen-4.0.3-1.el5 [root@fjs-0-10 ~]# only one version listed installed for the system on rhn yes.. cliff is correct.. There are two copies of the file listed in RHN... sat build 20 file-4.17-8 file-4.17-9.el5:0 and only one list on the command line.. [root@rlx-3-18 ~]# rpm -q --qf='%{n} %{v} %{r} %{ARCH} %{EPOCH}\n' file file 4.17 9.el5 i386 (none) Reassigning to jbowes for now. I'm totally out of my depth wrt to the interaction between yum, up2date, and RPM. Feel free to reassign back to me if this is incorrect. comment #32 is a symptom of bz 234880, which needs to be fixed in the plugin. So this bug is probably fixed, though the other isn't. Im not sure if this is really a test plan. But since no one has been able to provide one, it seems likely that the test plan is of form: 1) Ensure that nothing looks broken with package profile comparisions 2) Ensure snapshot rollbacks work as with previous expectations 3) Nothing else looks obviously broken in the data stored for systems and their associated packages. If all agree.. lets stick to this. Cliff. Transferring back to mmccune's queue so we can discuss next week. I'm not sure how to proceed on this one. Well, we used the "test" plan that Cliff outlined in comment 35 for rhn421's bug 235244. If there is going to be some more discussion about the change initiated by this bug and how to test it, we might need to retest rhn421's bug as well, with a better test plan. So far I had a feeling that we never had a good reproducer of this bug (it would have to be an rpm without epoch and a high version, vs. rpm with epoch = 0 and a low version). The results from comment 14 and comment 32 were either multilibs, or plugin problems, IMO. So basically we fixed the code because we felt the old approach could cause problems, and the test plan really is to see that the resulting behaviour is not worse than the original one. moving to ON_QA with the suggestion that we follow testplan in #35. verified.. Closed for Satellite 500 Release. |