On 12/10/2012 03:20 PM, Martin Sivak wrote:
Hi,
while working on #876716 I came over a particularly nasty issue we
have in our packaging code.
We execute everything in a thread while other threads are letting
the user setup his system. Unfortunately, RPM chroots immediately at
the beginning of the install transaction. As we use Yum in a library
form and Yum is using RPM also as a library.. well the process that
gets suddenly chrooted is anaconda itself.
Just FYI / to elaborate a bit:
It's not *a* chroot(), rpm switches in and out of the chroot constantly
during a transaction, not just at the start of a transaction. The first
chroot'ed operation is the "preparing..." stage, after than rpm does
chroot in and out for each and every installed and erased package in the
transaction.
This situation disrupts the environment anaconda uses for work and
most of the stuff stops working (because all the files we do not
have handle to are suddenly missing). It is not too visible atm as we
have a bare minimum of customization screens (only password). But we
(and other teams) will be adding more and this will get progressively
worse to workaround.
I have talked to Panu about libRPM and while he agreed with me that
calling chroot or exit in a library is an evil thing, he also said
that there is not much that can be done on the RPM side, because
some internal mechanisms like lua scripts need the root to be changed
this way.
That leaves to pieces where we can fix this:
Yum:
- yum could be modified to for a new process for the RPM transaction
and use stdin/out for status reporting.
- this would keep API for other apps using Yum (and would be the
cleanest solution as far as I can tell)
Anaconda:
- we could workaround this by forking a child process with the Yum
call and do the same thing
- this would fix only anaconda and wold be essentially workarounding
a behaviour of a library we do not directly use
Of course it should be technically possible to have rpm itself fork the
transaction to separate process too, and it's something I've
occasionally thought of doing to insulate the transaction execution from
things like "oops closed the wrong terminal".
But it's not exactly a matter of "just add a fork() + waitpid()",
there's a fair amount of state that would need to be somehow transferred
between the processes. Also some API users, notably yum, *expect* the
chroots to occur and would need changes to accommodate such a thing.
The question here is.. how hard is it to modify Yum to isolate the
chroot away from the user (Anaconda) and it is feasible for F18?
From the "make it somehow work for F18" POV I'd guess the easiest thing
would be doing it in anaconda: unlike rpm and yum, it doesn't have an
API it needs to guarantee for its users, and (because of that) its need
for transferring state across the fork border is also by far the
smallest of the three. As its AFAICT not doing fine-grained per-package
progress meter any more it might be "just" a matter of pushing package
names along with the total progress across pipes or such.
- Panu -
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
