From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020104 Description of problem: I used the RHN web site to view errata for my system. Several were listed, so I scheduled an update for my system. Upon checking my system after the scheduled update time, I found that instead of just the packages that had previously existed on my system having been upgraded, EVERY package that was listed in the errata had been installed on my system. In the case of KDE, this meant that every i18n package had been installed on my system, even though no i18n pacakges had been installed before. I found the same problem when I chose to install the vim updates. Version-Release number of selected component (if applicable): rhn_register-2.7.2-7.x.8 rhn_register-gnome-2.7.2-7.x.8 up2date-gnome-2.7.11-7.x.2 up2date-2.7.11-7.x.2 How reproducible: Always Steps to Reproduce: 1. Schedule an update of the system from the RHN web site for a given errata. 2. Wait until after the scheduled update time and view the packages installed. In the case of vim (to keep this small), instead of the previous two vim packages being installed (vim-common and vim-minimal), all four packages listed in the errata report were installed (vim-common, vim-minimal, vim-enhanced, and vim-X11). In my view, if it wasn't there before, chances are there was a reason for that. Don't add, only update. :-) Actual Results: Pre-update [ian@camelot ian]$ rpm -qa|grep vim vim-common-5.8-7 vim-minimal-5.8-7 Post-update [ian@camelot ian]$ rpm -qa|grep vim vim-enhanced-6.0-7.13 vim-X11-6.0-7.13 vim-minimal-6.0-7.13 vim-common-6.0-7.13 Expected Results: Pre-update [ian@camelot ian]$ rpm -qa|grep vim vim-common-5.8-7 vim-minimal-5.8-7 Post-update [ian@camelot ian]$ rpm -qa|grep vim vim-minimal-6.0-7.13 vim-common-6.0-7.13 Additional info:
I experienced with this with the telnet and openldap erratas. The telnet- server installation especially is quite disconcerting; ETA on fix?
dave, can you duplicate this? It seems to do the correct thing for me.
The rpm errata just bit Cisco fairly hard. It ended up installing some rpm documentation (rpm2html) which snuck in mysql. mysql! This makes it very difficult for Cisco because internal tools for technicians in call centers compare installed package lists to profiles with 'the right' list. Discrepancies are color coded for ease of analysis. All machines will be wrongly flagged. Please fix!
I have just attempted to duplicate it with the latest glibc errata to no avail. I removed the nscd (and nss_ldap) package, scheduled the errata update, watched it complete, and confirmed that ncsd was NOT installed. I have confirmed by inspecting the code that it will only update packages installed. If more packages are being installed, it must be because of missing dependencies. If you can reproduce it, please do the following. Run "rpm -Va" and "rpm -qa" first, saving the output. Then schedule the update on the website. Go back to the workstation and run "rhn_check -vvv" and save the output. Then once again run "rpm -Va" and save the output, as well as another "rpm -qa". Save the output and attach to this bug.
I think this one has been fixed by the latest round of up2date errata. It has definitely been an issue that bit us hard too (ie, scheduling an errata kernel and having ALL flavors of the kernel installed). Adrian, please confirm?
Created attachment 54945 [details] rpm -Va (before)
Created attachment 54946 [details] rpm -qa (before)
Created attachment 54947 [details] rhn_check -vvv
As you can see from the attachment, mysql and tux certainly don't belong. Working on the (after) attachments right now. We're trying to avoid having to put order on things (since it's numbers-based scheduling right now), but if we have to push the rhn client errata first, it would be good information to have. Please let me know one way or the other.
Created attachment 54948 [details] rpm -Va (after)
Created attachment 54949 [details] rpm -qa (after)
This is fixed in the errata according to all my personal testing. QA needs to close. Yes, you need to update to the fixed version first to get the fix. I belive there is another bug with this issue thats closed, though bugzilla is going awfully slow for me at the moment.
I'm attaching some sample output (alas, rhn_check with only one -v so I can more easily read it) as confirmation and closing . . .
Created attachment 55207 [details] rhn_check -v