Bug 208850 - RHN does not treat no epoch as epoch = 0
Summary: RHN does not treat no epoch as epoch = 0
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Other
Version: rhn500
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike McCune
QA Contact: wes hayutin
URL:
Whiteboard:
Keywords:
: 212240 212244 212614 (view as bug list)
Depends On: 212614
Blocks: 173427 210233 212240 212244
TreeView+ depends on / blocked
 
Reported: 2006-10-02 13:09 UTC by James Bowes
Modified: 2013-01-10 09:50 UTC (History)
4 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2007-06-26 03:02:40 UTC


Attachments (Terms of Use)
ss of problem (352.21 KB, image/png)
2007-02-15 16:12 UTC, wes hayutin
no flags Details

Description James Bowes 2006-10-02 13:09:53 UTC
RPM specifies that a package without an epoch should be considered to have an
epoch of 0. RHN treats them as different values.

This is a problem with package profile syncing from yum, since yum does the
correct thing and treats no epoch as epoch 0. When it sends this up to RHN, RHN
associates the wrong package with the system's profile.

Comment 1 Bret McMillan 2006-10-02 15:21:58 UTC
So, is this bug client-side or server-side?

Comment 2 James Bowes 2006-10-02 15:35:59 UTC
I'm inclined to believe it is server-side.

Comment 3 Jesus M. Rodriguez 2006-10-31 17:25:13 UTC
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.

Comment 4 Bret McMillan 2007-01-18 21:59:30 UTC
jesusr, can you state whether the java code got fixed?

Comment 5 James Bowes 2007-01-19 15:45:52 UTC
*** Bug 212244 has been marked as a duplicate of this bug. ***

Comment 6 Jesus M. Rodriguez 2007-01-19 22:37:51 UTC
The java code has NOT been fixed. If the plsql has been fixed, we can go ahead
and fix it in the java code.

Comment 7 Bret McMillan 2007-01-29 20:02:45 UTC
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 :)

Comment 8 Fanny Augustin 2007-01-29 22:36:47 UTC
Not a server side blocker.

Comment 9 RHEL Product and Program Management 2007-01-29 22:41:05 UTC
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.

Comment 10 Kevin A. Smith 2007-01-31 14:57:22 UTC
* 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.

Comment 11 James Bowes 2007-01-31 15:16:25 UTC
(In reply to comment #8)
> Not a server side blocker.

Uh, this is entirely server-side.



Comment 12 James Bowes 2007-01-31 15:20:06 UTC
(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.


Comment 13 wes hayutin 2007-02-15 16:12:39 UTC
Created attachment 148119 [details]
ss of problem

Comment 14 wes hayutin 2007-02-15 16:15:22 UTC
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...

Comment 15 Fanny Augustin 2007-02-27 18:30:18 UTC
Clearing the RHEL flag.  This is a Hosted 500 issue.  

Comment 16 James Bowes 2007-02-28 21:24:10 UTC
(In reply to comment #14)

> The above screen shot displays the same packages twice...

Those are probably 64bit and 32bit versions of the packages.



Comment 17 James Bowes 2007-02-28 21:24:57 UTC
*** Bug 212240 has been marked as a duplicate of this bug. ***

Comment 18 James Bowes 2007-02-28 21:28:03 UTC
*** Bug 212614 has been marked as a duplicate of this bug. ***

Comment 19 Jan Pazdziora 2007-03-30 09:45:11 UTC
Re comment 14: put the following line to your .rpmmacros to make sure they are
not multilibs:

%_query_all_fmt         %%{name}-%%{version}-%%{release}.%%{arch} 


Comment 29 wes hayutin 2007-04-04 18:24:40 UTC
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

Comment 32 wes hayutin 2007-04-16 19:55:41 UTC
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)



Comment 33 Kevin A. Smith 2007-04-16 20:04:13 UTC
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 34 James Bowes 2007-04-16 20:26:18 UTC
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.

Comment 35 Clifford Perry 2007-04-19 14:04:54 UTC
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. 

Comment 36 Kevin A. Smith 2007-04-26 13:42:50 UTC
Transferring back to mmccune's queue so we can discuss next week. I'm not sure
how to proceed on this one.

Comment 37 Jan Pazdziora 2007-04-30 12:04:50 UTC
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.

Comment 38 Mike McCune 2007-05-07 16:48:10 UTC
moving to ON_QA with the suggestion that we follow testplan in #35. 



Comment 39 wes hayutin 2007-05-07 17:04:31 UTC
verified..

Comment 43 Brandon Perkins 2007-06-26 03:02:40 UTC
Closed for Satellite 500 Release.


Note You need to log in before you can comment on or make changes to this bug.