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
