[packagekit] exclude some upgrades

[Richard Hughes]

On Mon, 2007-11-12 at 15:11 -0500, David Zeuthen wrote:
> On Mon, 2007-11-12 at 14:55 -0500, David Zeuthen wrote:
> > > >  - User is informed of this by PackageKit showing the update list
> > > >    but with some of the packages unchecked (GtkCheckButton)
> > > 
> > > No, if a user can't be applied then it shouldn't be shown in the package
> > > update list. The update list shows "updateable" packages.
> > 
> > How will the user know that some packages can't be updated then? In the
> > worst case you'd be leaving the system in a vulnerable state because
> > some security update can't get through. That would be bad.

No, we show the updates that can be applied. Any that can't be updated
shouldn't be shown (see below). The argument about being in a vulnerable
state isn't valid as we could not do the update if we wanted to. 

> Cracktastic ASCII mockup
> 
>  +----------+-----------------------------------------+
>  | Severity | Software                                |
>  +----------+-----------------------------------------+
>  | (normal) | git-1.5.3.4-2.fc9 (i386)                |
>  |          | Git core and tools                      |
>  +----------+-----------------------------------------+
>  |(security)| kernel-2.6.24-0.42.fc9 (i386)           | <-- greyed out!
>  |          | The core of the Linux operating system  |
>  +----------+-----------------------------------------+
> 
> where the kernel package is greyed out because it can't be updated. A
> tooltip (or other gizmos) will explain the user

We can do that in the current API, if we just add one enumerated type to
Package(), e.g. "blocked"

>  Update for 'kernel' is blocked by packages 'kmod-nvidia'
>  and 'kmod-ntfs'. <maybe more techno-babble including version numbers>

Getting the status is tricky, but we could append that in the package
description.

> This allows the user to understand what's going on. Advanced users will
> realize that if they remove kmod-nvidia and kmod-ntfs and make their
> system safe.

I don't think that's a valid argument - I wouldn't remove kmod-nvidia
just for a new kernel, I would just wait for livna to update. What if it
wasn't the case of removing one kmod, but you had to remove all of
openoffice because of a libneon security update?

> Or, you know, go and punk the providers of the packages
> that block. If you're feeling more cracktastic including a 'file a bug'
> button that automagically files a bug.

That really doesn't scale. Can you imagine closing 4500+ bugs of
"yesterdays rawhide didn't depsolve"?

Richard.