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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
