PackageKit does not respect "hold" state of packages.

[Ganton]

In some systems, you have to put "on hold" a package X to avoid it is updated. Then, if you execute
    sudo apt-get update && sudo apt-get dist-upgrade
it tells you that the package X is "on hold" and that is not going to be updated. Correct. But sooner or later appears the automatic graphical updating tool (I suppose it's Kpackagekit or "kubuntu-notification-helper") and tells you to update the package X! And this keeps happening from time to time, it doesn't learn or work OK.

WHAT IT IS EXPECTED TO HAPPEN
That the automatic graphical updating tool worked like the CLI tool and knew that when a package is "on hold"... must not be updated.

KUBUNTU VERSION:
Kubuntu 10.04

MORE INFORMATION:
    To put a package to hold:
    echo "package_name hold" | sudo dpkg --set-selections

    to 'unhold' it:
    echo "package_name install" | sudo dpkg --set-selecions

    To see which are your packages 'on hold':
    dpkg --get-selections | grep hold

[Ganton (ganton)]

STEPS TO REPRODUCE

When you are going to update your Kubuntu, you can try to "hold" a package before really doing it... and see the difference between the good behavior of "sudo apt-get update && sudo apt-get dist-upgrade" and the bad one of the graphical update program.

[Waleed Hamra (w-hamra1987)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in kpackagekit.
(With many applications, you can report a future bug directly on the appropriate package by opening the application's "Help" menu and choosing "Report a Problem". https://wiki.ubuntu.com/ReportingBugs)

[Waleed Hamra (w-hamra1987)]

willy@Hamra:~$ sudo aptitude update
[sudo] password for willy:
....
....
Reading package lists... Done

Current status: 1 update [+1].
willy@Hamra:~$ sudo aptitude full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following packages will be upgraded:
  skype
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.2MB of archives. After unpacking 505kB will be used.
Do you want to continue? [Y/n/?] ^C
willy@Hamra:~$ sudo echo "skype hold" | sudo dpkg --set-selections
willy@Hamra:~$ dpkg --get-selections | grep hold
skype hold
willy@Hamra:~$ sudo aptitude full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Writing extended state information... Done
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
Writing extended state information... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done

so far so good. i start kpackagekit, and it asks for updating skype.
the problem it seems that kpackagekit does not read/respect dpkg's preferences.
incidentally though, it DOES respect apt's pinning options. so if you pin a package, use a negative pin priority for it, you achieve a hold-like scenario. for more information, https://help.ubuntu.com/community/PinningHowto

[Ganton (ganton)]

God bless you, William! It worked! You saved me lots of time, if it may be useful I write what I did to "pin" Ktimetracker and not use its version of Lucid:

Edit
     /etc/apt/preferences
and write inside:
      Package: ktimetracker
      Pin: release a=lucid
      Pin-Priority: -10

[Jonathan Thomas (echidnaman)]

This is a problem with the python-apt-based PackageKit backend reporting the package as upgradeable. (The in-progress aptcc backend successfully notes the blocked status of held updates)

[Sebastian Heinlein (glatzor)]

The apt backend performs a safe upgrade by default and additionally tries to detect upgrades which would only require the installation of further packages but not the removal of those.

This methods makes it impossible to detect packages which are set on hold on the dpkg level, since apt doesn't provide information why an upgrade was skipped from the safe upgrade.

The aptcc backend doesn't perform a safe upgrade but a full upgrade to detect the updates. Since there isn't any simulate method for a system upgrade it is very dangerous of the aptcc backend to report upgrades as installable without having the possibilty to inform the user about the required removal of packages.

The best fix would be to have a simualte method for the upgrade_system method.

[Matthias Klumpp (ximion)]

I think this issue is fixed, as we use the APTcc backend by default in Ubuntu and Debian and actions are simulated before an upgrade is performed.
(If this issue is still present, please reopen this bug report)

[Andreas Raster (rakete)]

I am still having this issue in Kubuntu lucid. But I can't reopen the bug.