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

Re: Anaconda threads and Yum with rpm backend



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"..

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 :)
- 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

2) Disable dictionary checks in password spoke
- the chroot will still happen, but it won't show
- obviously our password checking would get worse
- we would get some time to fix this for next release at the proper place

3) File a bug against pwcheck so it is not calling exit() when the dictionary is not present
- the fix might not be ready for F18 
- the same comments as for 2)
- we should do this anyways

Martin

----- Original Message -----
> > 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
> 
> Ouch.  Well, I would definitely prefer this to be fixed outside of
> anaconda.  However, realistically we're probably stuck for F18.  So I
> guess no matter what happens in the future, we've got to come up with
> something for now.
> 
> 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.
> 
> - Chris
> 
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list redhat com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
> 


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