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

[Richard Hughes]

On 02/09/07, Tom Parker <palfrey at tevp.net> wrote:
> 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.

Yes, good summary.

> (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).

Yes, can you dump this into helpers/README please as NOTES to the
respective sections or just at the top. Thanks.

> 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).

Sure, that's up to the backend, or rather, up to you :-)

Thanks,

Richard