[packagekit] Semantic issues with GetDeps (and other interface functions)

[Tom Parker]

Richard Hughes wrote:
> We should never remove packages to satisfy a dep. If wizzybar depended
> on libraries not compatible with gimp, then we fail, and let the
> distro sort it out on the next push. The user shouldn't have to
> choose, no matter how buggered the repo is.

> I don't think this belongs in the UI, we need to keep it simple and
> effective. Remember, power user still have aptitude and yum on the
> command line, PackageKit should focus on the "I don't care how it
> works just do it" technical challenge.

'k. I think I've got a better handle on the sort of dependancy 
resolution we want here. I think a reasonable summary is

* Pull in all "suggested" or "recommended" packages, as they will help 
the user actually use the package they're asking to install.
* Don't remove anything unless explicitly requested.
* If we can't install a package *without* removing other things, fail 
(with PK_TASK_ERROR_CODE_DEP_RESOLUTION_FAILED I presume). Assume that 
this doesn't happen very often, and that there's another way to install 
packages using the native packaging system.

(Things like this may want to make their way into some docs at some 
point for future backend writers that aren't necessarily reading this 
mailing list right now).

For the Apt backend, I may well stick with the aptitude-style points 
system for considering multiple possible dependancy resolutions, and 
step through them until one is found that doesn't remove anything and 
return that as the dependancies for a package (or fail if there isn't one).

Tom