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. 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 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? -- Martin Sivák msivak@xxxxxxxxxx Red Hat Czech Anaconda team / Brno, CZ _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
