[packagekit] Accept Eula

[Richard Hughes]

On Fri, 2008-08-22 at 11:39 -0700, dantti85-pk at yahoo.com.br wrote: 
> You select a big package to install,
> call installPackages(pids), ok this will take a while
> then you decide to install more packages
> but this time installPackages got queued,
> this 2nd installpackages has a package that need
> to accept eula.
> So i think you will only know that when the 1st
> transaction finishes...

Sure.

> As it will take a while you logout, and login...
> now i have two thing i don't know (just figured out one more :P )
> * the 1st transaction finishes and how do you
> have a popup that has to accept eula?
> (this includes more problems... )

You probably want to see the GpkClient ::finished code -- if the
Finished handler has the error code of key_required, then we know we
need to do something before we can requeue the transaction.

> * ok, now you click on the tray icon and select the 
> 2nd, transaction in one minute the 1st one finishes and
> the 2nd emmit accept eula, you agree (as always :) )
> and then installPackages must be called again.
> Now, does the getRole return packagesId so i can discover
> what was asked to install? i mean i'll will be ugly to store
> this data on the gui side (if the relogin switechs form kde
> to gnome).

I don't think you need to store this across session switches.

> * when the user is going to accept the X crashes
> so he will never see the 2nd transaction anymore..
> as it is Finished(accept eula)

Don't worry about X crashes.

> Adrien and i thought that this way should change
> A Finished transaction should be really finished.

No, a finished transaction means that the backend has done all that it
can at that point. If it finished with exit success, then we know it is
complete, else we have to do something (a new transaction) and then we
can requeue the original transaction so it completes with success.

> If you are waiting to install signature or accept
> eula you shoud be at status Accept eula,

No. If you block the transaction then no other transactions can be run.
Let me give an example.

User clicks "install vmware"
User walks away
---
System upgrade is scheduled (300Mb of updates)

In the current case, the vmware package is downloaded, but cannot be
installed until a EULA is agreed to. If we pause the transaction then we
never apply the updates and the user has to wait a substantial amount of
time to do this after clicking "I agree".

In the current system the first transaction downloads vmware, and then
it finishes, and puts up a UI for the user to click. In the meantime the
second transaction (the update) is scheduled, downloaded and installed,
and then finishes.

The user returns, clicks "okay" and a third transaction is created that
accepts the eula, and a forth that actually installs vmware.

It seems complicated, but it's essential to make sure none of the
callbacks block and stop other transactions from happening. There's tons
more detail here:
http://www.packagekit.org/gtk-doc/introduction-ideas-transactions.html

> this way when the X crash (i'm just creating a possibility :) )
> you will still be able to click on the tray icon
> "Installing Packages vim ( waiting for eula to be accepted)"
> and when you accept it the transaction continues.
> And only finishes if the user does not accept the eula
> or a error really happen.

No, if X crashes you loose state, and you have to start again with the
original action. If you start looking at preserving persistent state in
the client you're going to do a _lot_ of caching and writing to disk. I
would strongly advise not to do this.

> Also if the user click on the :
> "Installing Packages vim ( waiting for eula to be accepted)"
> the transaction UI can check the get status() and
> see that "waiting for eula to be accepted", and
> it can then ask for the eula again so he can continue to read
> from where he stopped as the X crashed :P

No, I don't think this is a valid use case. If X crashes then we need to
file a bug and get it fixed, not design complicated state saving clients
for such a trivial job.

Richard.