http://bugzilla.novell.com/show_bug.cgi?id=627316 http://bugzilla.novell.com/show_bug.cgi?id=627316#c6 Geoff Farrell <gfarrell@netspeed.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gfarrell@netspeed.com.au --- Comment #6 from Geoff Farrell <gfarrell@netspeed.com.au> 2010-08-16 10:00:23 UTC --- It may be true that libzypp's handling of locked patches was faulty, but it isn't the cause of this bug. Instead of having to lock a patch, it would be preferable for kupdateapplet to correctly assess the requirement for an update in the first place. In this instance, these are the k3b package details: Updates repository: k3b-2.0.0-1.1.1.x86_64.rpm, date compiled: 22 Jul 2010 18:55:59 UTC Packman repository: k3b-2.0.0-1.pm.2.14.x86_64.rpm, date compiled: 08 Aug 2010 01:31:59 UTC On both version number and date, the 'updates' repository package does not qualify as an 'update' if the Packman package is installed. Flagging it as an update when it's not is the bug. Making the user 'lock' the patch is just papering over the bug. As well, on my system, I have the Updates repository set at a priority of 90, and the Packman repository set at 80. Therefore, regardless of kupdateapplet's assessment of the packages' version numbers, the repository priority should block the update from being flagged. Since it doesn't, kupdateapplet fails on a second count here. To fix this bug, there seem to be two things that need to be corrected: 1. kupdateapplet does not correctly assess patches according to version, and 2. It does not filter patches according to repository priority. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.