<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Has non-interactive debconf support been in PK for sometime or is this new in the 0.5 series?<br><br><br><br><br><br>&gt; Date: Fri, 25 Sep 2009 08:35:19 +0100<br>&gt; From: hughsient@gmail.com<br>&gt; To: packagekit@lists.freedesktop.org<br>&gt; Subject: Re: [packagekit] Debconf and PackageKit Was Re: Packagekit and        Ubuntu<br>&gt; <br>&gt; 2009/9/24 Sebastian Heinlein &lt;sebi@glatzor.de&gt;:<br>&gt; &gt; I have made up this plan to integrate debconf and conf file conflicts<br>&gt; &gt; into PackageKit. These issues will be handled during a running<br>&gt; &gt; transaction which will paused while waiting for an answer from the<br>&gt; &gt; user - new transaction will be blocked so long. To avoid an endless<br>&gt; &gt; block the caller-active property and a time out will be used.<br>&gt; <br>&gt; If that's what we have to do, that's what we have to do. I can't say I<br>&gt; like it, but if we can run things un-attended, ten it doesn't break<br>&gt; too many of the use cases.<br>&gt; <br>&gt; &gt; If the backend recognizes a conf file conflict, pauses the transaction<br>&gt; &gt; and reports this to the packagekit daemon. The daemon checks if the<br>&gt; &gt; caller is still active. If so it sends a ConfigFileConlift signal with<br>&gt; &gt; the old and new file as attributes. The user would call a<br>&gt; &gt; ResolveConfigFileConflict method with the new file or possible<br>&gt; &gt; predefined values like "keep" or "replace". The daemon sends the<br>&gt; &gt; answer to the backend.<br>&gt; <br>&gt; Sounds sane.<br>&gt; <br>&gt; &gt; If the caller is no longer available on the bus the daemon will report<br>&gt; &gt; this to the backend, which will choose a default action.<br>&gt; <br>&gt; Doesn't the backend know if the caller is active or not?<br>&gt; <br>&gt; &gt; Would be basically the same as for config file conflicts. We could<br>&gt; &gt; use the proxy debconf frontend. This allows to communicate with<br>&gt; &gt; debconf using a socket. The backend would listen on the socket and<br>&gt; &gt; behave like a normal debconf frontend. A configuration question would<br>&gt; &gt; be send to the backend and from the daemon to the user using a signal.<br>&gt; &gt; The signal would need some further thinking since there are different<br>&gt; &gt; kind of possible questions e.g. yes/no, lists. See above for answer and<br>&gt; &gt; caller-active handling.<br>&gt; <br>&gt; Right.<br>&gt; <br>&gt; &gt; A further issue is the communication with the backend. Currently we<br>&gt; &gt; cannot access the caller-active property from a spawned backend.<br>&gt; &gt; Should we send this information to the backend or limit this advanced<br>&gt; &gt; features to native backends?<br>&gt; <br>&gt; There's no reason why we can't proxy this, the problem is that<br>&gt; typically we set the data as environment variables (NETWORK etc) which<br>&gt; don't change during the transaction. I'm not sure if you can change an<br>&gt; running process' environment. Other ways to contact the running<br>&gt; instance is just to dump more stuff to stdin, but if it's like the yum<br>&gt; backend it's blocking whilst it's running to command.<br>&gt; <br>&gt; Either way, I think it's best if the backend itself knows if the<br>&gt; caller is active or not.<br>&gt; <br>&gt; Richard.<br>&gt; <br>&gt; p.s. Thanks for working on this.<br>&gt; _______________________________________________<br>&gt; PackageKit mailing list<br>&gt; PackageKit@lists.freedesktop.org<br>&gt; http://lists.freedesktop.org/mailman/listinfo/packagekit<br>                                               <br /><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>