[packagekit] Adding a recursive flag to GetDepends and GetRequires

[Richard Hughes]

On Thu, 2007-11-08 at 12:50 +0100, Sebastian Heinlein wrote:
> Am Donnerstag, den 08.11.2007, 09:23 +0100 schrieb Tim Lauridsen
> > * Add some actions/packages to the Transaction
> > * Resolve dependencies.
> > * Ask for confirmation
> > * Process the Transaction.
> > 
> > This is even more useful if we want to extend to take more than one
> > package id as an argument.

This isn't part of the API and won't be supported. Adding multiple
package_id's to transactions introduces a whole heap of other changes
that we just don't need. The API should stay completely flat.

> I think that this is a better approach. Sometime installing a package
> also requires to update other packages or to remove other. Furthermore
> the required changes should be calculated by the backend and not the
> frontend. If you use GetRequires you would have to check for installed
> requirements. In the end you would move the resolver to PackageKit.

No, I don't think this is right; it's what package managers have done in
the past, but it's not the sort of user experience I want with
packagekit. I'll explain why:

At the moment, a user wants to install the epiphany browser as he's
heard good things about it. He goes to Add/Remove programs, searches for
epiphany, and clicks install. With the current code, the
InstallPackage(package_id) method is called, and any deps are downloaded
and installed automatically in the background. That's what we want; the
user _just_ wants to install epiphany and PackageKit does does the right
thing. As the InstallPackage transaction is setting up and downloading
he can browse other software and queue that up too.

Using the traditional "pre-commit, commit" type transaction stops us
doing this, and provides the user with information he does not need or
want to know. For instance, the user searches for epiphany, clicks
install which fires the InstallPackage method with the package_id. This
does a pre-commit dummy run, and presents to the user "To install
epiphany, PackageKit needs to install epiphany, install
ephiphany-extensions, update gnutls and update glibc, okay to continue?"

This dialog would mean nothing to the average user, and he will just
click "okay" to get the software that he wants to install. What I'm
trying to say is that such a dialog just gets in the way of the users
primary goal and actually achieves little. The other point to mention is
that a pre-commit also takes quite a few seconds to do (up to a couple
of minutes if it's a large yum-update) and the dialog will have to be
presented to the user after this step has been taken. Either we block
the UI and just give the user a pulsing progress bar to look at with no
real UI, or we end up prompting the user a few minute later about an
action that he explicitly requested and thought was going on in the
background.

This sort of thing is also not needed by the update tool, as when the
user calls UpdateSystem, that's what he wants to do - he doesn't care
about exactly what is done; it's fire and forget. In the case of an
automatic update we just trust the backend to do the right thing, and
that's exactly what it should do.

> A kind of callback would perhaps be a better way.

Well, we have to assume that package dependencies are correct, and
removing a package doesn't do insane things. If we keep this assumption
then we can filter the packages that are installed or available and
present a sane list to the user _before_ the transaction is run; this is
the main reason of putting the Requires checking right in the client
tool and not in the daemon or backend. This also lets us do insane
things like greying out the remove button if one of the requires is a
protected system package and other cleverness like that.

We also have to bear in mind that some of the backends could not do
pre-commits due to design decisions or other limitations, and therefore
we would need to report this back to the daemon and client tools so
other, different, methods could be used

I do understand why some distros might want this "feature". For example
if you were installing epiphany and the transaction was forced to remove
galeon, i.e. the update or install removes other software that the user
may care about. 

In this case the packagers are insane and the packages need to be fixed
so both can be installed. :-) Does that explain things better?

Richard