[packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu

[Richard Hughes]

2009/9/24 Sebastian Heinlein <sebi at glatzor.de>:
> I have made up this plan to integrate debconf and conf file conflicts
> into PackageKit. These issues will be handled during a running
> transaction which will paused while waiting for an answer from the
> user - new transaction will be blocked so long. To avoid an endless
> block the caller-active property and a time out will be used.

If that's what we have to do, that's what we have to do. I can't say I
like it, but if we can run things un-attended, ten it doesn't break
too many of the use cases.

> If the backend recognizes a conf file conflict, pauses the transaction
> and reports this to the packagekit daemon. The daemon checks if the
> caller is still active. If so it sends a ConfigFileConlift signal with
> the old and new file as attributes. The user would call a
> ResolveConfigFileConflict method with the new file or possible
> predefined values like "keep" or "replace". The daemon sends the
> answer to the backend.

Sounds sane.

> If the caller is no longer available on the bus the daemon will report
> this to the backend, which will choose a default action.

Doesn't the backend know if the caller is active or not?

> Would be basically the same as for config file conflicts. We could
> use the proxy debconf frontend. This allows to communicate with
> debconf using a socket. The backend would listen on the socket and
> behave like a normal debconf frontend. A configuration question would
> be send to the backend and from the daemon to the user using a signal.
> The signal would need some further thinking since there are different
> kind of possible questions e.g. yes/no, lists. See above for answer and
> caller-active handling.

Right.

> A further issue is the communication with the backend. Currently we
> cannot access the caller-active property from a spawned backend.
> Should we send this information to the backend or limit this advanced
> features to native backends?

There's no reason why we can't proxy this, the problem is that
typically we set the data as environment variables (NETWORK etc) which
don't change during the transaction. I'm not sure if you can change an
running process' environment. Other ways to contact the running
instance is just to dump more stuff to stdin, but if it's like the yum
backend it's blocking whilst it's running to command.

Either way, I think it's best if the backend itself knows if the
caller is active or not.

Richard.

p.s. Thanks for working on this.