[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Anaconda threads and Yum with rpm backend



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 -


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]