Guys, you are totally missing that there is an intermediate layer between rpm and anaconda that is well suited for this. Yes I am talking about Yum. Anaconda has (theoretical) support for multiple backends and doing the fork and inventing new protocol just because one of them uses a library which should have a process for itself is not clean. Yum should simply isolate all the API users from the low level operations. That will fix chroot issues, selinux contexts, capabilities, ... once and for everybody. Martin ----- Original Message ----- > On 12/13/2012 10:36 AM, Vratislav Podzimek wrote: > > 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. > > Oh it might not be "that different" for any remotely normal > activitity. > The big difference is trying to do something unrelated while an rpm > transaction is running within the same process. librpm imposes all > sorts > of nasty statefulness via its API, some of percolating up from the > libdb > programming model, but most of all from librpm "design" being more of > a > means to implement the rpm cli application than a nice and > well-behaved > library as we expect them these days. > > > > > 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. > > On a related note, I seem to recall PackageKit running transactions > in a > separate process. Might be worth checking out - even if perhaps not > usable as-is, it could provide a starting point and avoid reinventing > everything from scratch. > > - Panu - > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
