List Archive: gentoo-portage-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Fri, Nov 18, 2005 at 11:09:14AM -0800, Zac Medico wrote:
> Brian Harring wrote:
> >The modification is pretty straight forward offhand; the notable
> >difference this time around is rather then extending portage_exec to
> >have the capability to 'spawn' python funcs (something I always found
> >ugly), this handles the fork itself.
> This patch seems to work well for me. I suggest that we add some sort of
> logging ability so that possible fetch problems will be easier to diagnose.
Note that due to how it's implemented, this does two rounds of
verification- it'll actually do *two* rounds of fetching too, if
things go awry in the backgrounded thread.
Logging info is possible, but outputting to the term is nasty- need to
basically have a message interface (imo) to dump it sanely, rather
then dumping messages from the background fetcher whenever they
arrive. Yes python locks print on it's own, but we also have a lot
of sys.stdout abuse in use.
Personally? Screw background logging. If it fails in the background
fetcher, it'll rear it's head in the foreground giving immediate display.
If you try to go through and integrate some type of output to the
term for the background fetcher, you're going to have to do a *lot* of
arg passing into and out of digest/fetcher to make it remain silent.
I did this in ebd, and it was _not_ a simple patch. Cost outweighs
the gain imo (hence the massively simplified patch for stable).
Could keep the old stderr fd around, and write to it when a fetch has
failed I spose, but again, don't think it's worth it.