[packagekit] Semantic issues with GetDeps (and other interface functions)
palfrey at tevp.net
Sun Sep 2 14:41:35 PDT 2007
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).
More information about the PackageKit