[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Anaconda threads and Yum with rpm backend

On Thu, 2012-12-13 at 10:08 +0200, Panu Matilainen wrote:
> > If we have to workaround it, we have three possible actions to take:
> >
> > 1) Workaround the chroot in anaconda
> > - if we do this, Yum and RPM would loose the motivation to fix it at their side :)
> Heh. While that's not entirely untrue either, anaconda suddenly doing 
> something different is not really *the* motivation for fundamentally 
> changing how librpm has always gone about its business. From rpm POV the 
> bigger motivation is protecting the transaction itself from things like 
> GUI-level bug bringing down the entire thing while in middle of 
> transaction, accidentally closing a terminal where rpm/yum/whatever is 
> running and so on.
While I understand your reasoning, I'd like to point out that anaconda
is not doing anything "that different". It just uses multiple threads
and lets Gtk main-loop run correctly. I believe that running everything
in a single thread and stepping main-loop in the callbacks is worse evil
than some interprocess communication. 

Maybe we could use a DBus service (yeah, I know, hunting sparrows with a
cannon) and just emit signals and provide two methods -- for skipping
package and continuing the installation and for aborting installation.
This way we wouldn't need to invent any "new protocol" and force pipes
not to work in a default block-buffered mode. Moreover some other
component in the future would be able to listen these signals too.

Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]