[packagekit] Ignoring updates

[Robin Norwood]

On Tue, 15 Apr 2008 19:27:00 +0100
Richard Hughes <hughsient at gmail.com> wrote:

> On Tue, 2008-04-15 at 12:28 -0400, Robin Norwood wrote:
> > And, if the user *does* explicitly say "don't update this" and then
> > we say "sorry, we updated it anyway..."
> > 
> > <cliche>What are the use cases we're trying to solve?</cliche>
> 
> Okay, can we say that the UpdatePackages method won't drag in extra
> deps? And if it does, FAIL? This needs serious discussion I would say,
> as we use BASENAME to reduce the list of updates, so can't just put a
> naive check in for added deps, as the BASENAME will have hidden some.

That doesn't seem very useful either - if I see that there's a new
version of firefox that I want to cherrypick and update, I don't want
to have to specify all of the deps it needs.

The use case I can think of for not updating a given package when
doing a general update is that the user already knows that the latest
version is broken for him.  For instance:

Collin updates to the latest packages for F9.  He reboots, and finds
that X crashes for him.  After much frustration, he discovers that the
cause is the updated driver for his video card.  So he manages to
downgrade to the previous version (I can hear the conary guys muttering
about 'rollback' now. :-)).  He reboots, and now that he has X back, he
sees that there is an update...the video card driver he knows will
break his system.  So he clicks on the update and says "Don't ever
apply this update".

A few days later, he gets another set of updates, including an even
newer version of X and the video card driver.  He gets a message saying
he can't upgrade X because it depends on a newer version of the video
card driver than the one he has installed.  He notices that the video
card driver is even newer than the one he knows breaks his system, so
he removes the block on the update, and crosses his fingers.

Does this cover it?  In this thought experiment, Collin wants:

o An easy way to say "Don't apply this update"
o Notification that not applying that update is blocking other updates.
o An easy way to remove the block when he decides it is safe to risk
the update again.

Based upon this, I think we should block all updates to <packagename>
but it would be good to store somewhere which specific version of the
package the user blocked, so we can say "A newer version of foo is
available, would you like to unblock it?"

Anyone have another use case?

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching