Pinned hardy repository causes update-manger to fail but shows no error message

Bug #203659 reported by Siegfried Gevatter on 2008-03-18
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: update-manager

I tried to upgrade from Gutsy to Hardy («update-manager -d») having all Hardy packages pinned (*). The result was that update-manager removed a single package (the old GNOME Printer Management GUI, I don't remember the name of the package), did nothing on the "installing packages" step, then was for about half an hour on the "cleaning" step (without doing anything at all) and then it just crashed (it gave a traceback but I didn't think about copying it, sorry).

It would be better if update-manager noticed that all Hardy packages are pinned, showed an error dialog and asked if it should unpin them.

--------------------------------------------------------------------------------
* In file «/etc/apt/preferences»:
    Explanation: Hardy packages have a lower priority
    Package: *
    Pin: release a=hardy
    Pin-Priority: 75

Changed in update-manager:
importance: Undecided → Low

I can confirm this. Followed the steps in the previous post and got identical output. Log files to follow.

Changed in update-manager:
status: New → Confirmed
Michael Vogt (mvo) on 2008-04-28
Changed in update-manager:
milestone: none → later

I was in the same situation for the Intrepid->Jaunty upgrade, with the jaunty repository pinned to priority 50. Arguably the situation improved, since the upgrade did not crash, but it only upgraded a limited number of packages (including the new kernel). Also after upgrade finished and after reboot it still offered upgrade to the new jaunty 9.04, as if upgrade wasn't registered.

Since it is sometimes necessary to upgrade selected packages to the next version, and pinning to a low priority is a convenient way to manage this mix, I think this situation is (relatively) frequent and it would be great if it could be handled more gracefully. It could be handled similarly to the third-party repositories, which are automatically disabled on upgrade. There should at least be a warning if /etc/apt/preferences is present, or the option to disable all pinning before starting the upgrade.

ski (skibrianski) wrote :

I had this from hardy -> lucid. One pinned rdiff-backup package triggered a requirement on a specific old version of python, which caused heck to break loose.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments