[packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu
jean_p57 at hotmail.com
Thu Oct 22 10:08:22 PDT 2009
Thanks Daniel, that was quick.
Change this how?
> Date: Thu, 22 Oct 2009 09:59:27 -0700
> From: dantti85-pk at yahoo.com.br
> To: packagekit at lists.freedesktop.org
> Subject: Re: [packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu
> It has been there for a long time,
> but hopefully in a few days the new
> dbus frontend will change this.
> >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
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
New Windows 7: Find the right PC for you. Learn more.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PackageKit