On 12/11/2012 01:12 PM, Martin Sivak wrote:
Hi,
My answer largely depends on the answer to this question: What's the
last thing happening in the anaconda packaging thread before the
chroot
happens? I'm trying to get some idea of how much communication takes
place between the packaging thread and others. If it's not much,
we're
in luck. If it's a lot, we're in trouble.
It happens between somewhere late in the "Starting package
installation process" and installing the first package. I was not able
to pinpoint it better since RPM is not holding the chroot stable (it is
releasing it and acquiring as needed) and Python threads got switched at
inconvenient moments so my debug prints were telling me I am chrooted
and unchrooted at the "same time"..
FWIW, the progress callbacks roughly indicate where it is: all the
rpm.RPMCALLBACK_TRANS_* events occur inside a chroot -
rpm.RPMCALLBACK_TRANS_START occurs right after the first switch into
chroot, rpm.RPMCALLBACK_TRANS_STOP right before switching out of it.
rpm.RPMCALLBACK_INST_OPEN_FILE and rpm.RPMCALLBACK_INST_CLOSE_FILE occur
outside the chroot (especially OPEN_FILE has to be there), IIRC
everything else occurs inside the chroot.
Of course that doesn't help anything at all, even if one tried to
somehow synchronize with the callbacks there's always a window of time
between the actual chroot and the callback event.
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.
Another unrelated motivation towards such changes comes from SELinux
(and other similar) camps like which would prefer limiting the amount of
code running in the rather omnipotent rpm_exec_t context.
- we will have to invent a pipe based protocol for progress and error reporting + user's choices (bidirectional)
- we will have and ugly hack at the wrong place
Some kind of pipe-based, bi-directional protocol would be needed on
yum/rpm level as well, only for considerably more data and other issues
to somehow resolve: like mentioned some API users *expect* the chroots
to occur in-process so if done on rpm level, it potentially requires
changes to various pieces living on top of librpm. I guess a at least
yum would only be happy to not have to worry about chroots, but it'd
likely need to carry code for both behaviors to avoid suddenly growing a
dependency on a very new rpm version.
So while I dont disagree such a thing would ultimately belong to librpm
level, doing it is not exactly easy. The earliest possible opportunity
for a change of that magnitude would be rpm 4.12 which would mean Fedora
>= 20. And that's earliest possible *in theory*, we're talking about
quite a drastic change in an old codebase deeply wired to the assumption
of running entirely within a single process.
- Panu -
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
