[packagekit] exclude some upgrades
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
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
User: "My system updates automatically, but won't when I do it manually."
More information about the PackageKit