<html> <head> <style></style> </head> <body class='hmmessage'> Has non-interactive debconf support been in PK for sometime or is this new in the 0.5 series? > Date: Fri, 25 Sep 2009 08:35:19 +0100 > From: hughsient@gmail.com > To: packagekit@lists.freedesktop.org > Subject: Re: [packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu > > 2009/9/24 Sebastian Heinlein <sebi@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. > _______________________________________________ > PackageKit mailing list > PackageKit@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/packagekit <hr />New Windows 7: Simplify what you do everyday. <a href='http://windows.microsoft.com/shop' target='_new'>Find the right PC for you.</a></body> </html>