Bug 188325 - GUI shows package needs updating yet is at most recent rev
GUI shows package needs updating yet is at most recent rev
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Solaris (Show other bugs)
500
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Vetere
Clifford Perry
: Reopened
Depends On:
Blocks: 196477
  Show dependency treegraph
 
Reported: 2006-04-07 17:02 EDT by Mike McCune
Modified: 2007-06-26 11:11 EDT (History)
4 users (show)

See Also:
Fixed In Version: rhn410
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-19 18:10:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
CBLTwget (617.90 KB, application/octet-stream)
2006-05-16 09:04 EDT, Pete Vetere
no flags Details

  None (edit)
Description Mike McCune 2006-04-07 17:02:23 EDT
1: Creating a Solaris base channel
2: Subscribe a solaris system to this base channel
3: Upload a package to the solaris channel
4: Schedule the package for installation via the GUI
5: Run rhn_check on the solaris host (It will download and install the package)
6: Look at the current state of the db.  It says there's one update available
(the just installed package). 
7. Look at the package list for the system, and it has the package recorded as
installed (which it is)
8.  Wonder if this custom package has a version numbering problem?
Comment 2 Mike McCune 2006-04-07 17:11:10 EDT
(12:05:37) pvetere: blc: interesting problem you found
(12:05:45) pvetere: blc: wouldn't be surprised if it's a bug
(12:13:57) pvetere: blc: i looked at your system... it's definitely a bug. 
can't explain why it happened without some more detailed investigation
(12:14:03) pvetere: blc: but i haven't seen it before
(12:14:54) pvetere: blc: it's possible that for some reason the server has a
different md5 for the pkg in the channel than was computed by the package on the
client
Comment 5 Shannon Hughes 2006-05-03 11:24:52 EDT
ran through a couple iterations and did not see any isues with pvetere. agreed
to close as worksforme
Comment 6 Shannon Hughes 2006-05-10 14:31:54 EDT
pvetere has a system he can reproduce...opening this one back up
Comment 7 Shannon Hughes 2006-05-10 14:32:27 EDT
shughes blc, k, will open it back up. 
blc shughes: btw, the client system is now solaris10-1.farm.hsv.redhat.com. 
otherwise everything is the same.
Comment 8 Shannon Hughes 2006-05-11 13:50:09 EDT
looks like the rhnServerOutdatedPackages table is not being updated correctly, 

SQL> select sop.package_name_id as name_id, max(pe.evr) evr
  2  from rhnPackageEVR PE, rhnServerOutdatedPackages SOP
  3  where sop.server_id = 1000010019
  4  and sop.package_evr_id = pe.id
  5  group by sop.package_name_id;

   NAME_ID
----------
EVR(EPOCH, VERSION, RELEASE)
--------------------------------------------------------------------------------
     2681
EVR_T(NULL, '1.8.2-1', '1')

SQL> select name from rhnpackagename where id = 2681;

NAME
--------------------------------------------------------------------------------CBLTwget


Going to pass on to pvetere to take a look at the backend and how it updates
this table after packages are updated. 
Comment 9 Pete Vetere 2006-05-16 09:00:54 EDT
Fixed.  The package revision was incorrectly being built in situations where the
version had the format x-y-z (1.8.2-1-1, in this case).  The bug was that the
version became 'x' and the revision became 'y z'.  However, the server wants the
following format: version='x-y', revision='z'.  I've adjusted the code to
produce the latter.
Comment 10 Pete Vetere 2006-05-16 09:04:09 EDT
Created attachment 129189 [details]
CBLTwget

Test package
Comment 13 Beth Nackashi 2006-07-19 18:10:27 EDT
closing -- currentrelease

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