[packagekit] exclude some upgrades

Richard Hughes hughsient at gmail.com
Mon Nov 12 12:40:33 PST 2007

On Mon, 2007-11-12 at 15:17 -0500, Robin Norwood wrote:
> Is this something that never happens in other distros/packaging systems?
> If so, then I can see why we might want to put the logic in the
> yum-specific parts.  Otherwise, if it's something than can be handled in
> an abstract way, why not put it in the engine so all backends can
> benefit?

I don't think we can put this in the daemon, it requires too many back
and forwards calls to something like a depsolver.

> >>  - 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.
> Hrm.  In a way, this makes sense - but then how should PK tell the user
> that there are packages that can't be updated?  Also, I think at least
> with the yum backend, testing the update set before displaying it to the
> user will take much longer than just showing the available updates.  I
> could be mistaken, though.

Sure. Adding the "invalid" or "cant-apply" INFO enum might be enough for

> What if:
> o PK attempts an update
> o Update fails because of deps
> Automatic mode:
> o PK does the updates it can do, and reports the parts it couldn't.
> Interactive mode:
> o PK brings up a dialog, and shows the user which ones it can't do, and
> lets the user Continue and do the updates it can do, or Cancel.

We don't differentiate between automatic and manual methods - I don't
think doing so (and haveing behaviour specific to each) is a good thing
to do.

User: "My system updates automatically, but won't when I do it manually."


More information about the PackageKit mailing list