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

[Daniel Nicoletti]

Yes,
It has been there for a long time,
but hopefully in a few days the new
dbus frontend will change this.

Daniel.


>
>De: Jean Hubbard
>Assunto: Re: [packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu
>
> > >
>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 at gmail.com
>> To: packagekit at lists.freedesktop.org
>> Subject: Re: [packagekit] Debconf and PackageKit Was Re: Packagekit and    Ubuntu
>> 
>> 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.
>> _______________________________________________
>> PackageKit mailing list
>> PackageKit at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/packagekit
>
>________________________________
New Windows 7: Simplify what you do everyday. Find the right PC for you.


      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com