On Tue, 2004-02-24 at 22:25 -0600, David Farning wrote:
> > This is kinda moot, of course b/c this part is disappearing.
> >
> > Have you looked at yum-HEAD/rpmUtils/updates.py and arch.py?
> >
> > That's where the new arch stuff is and I think the biarch support there
> > is A LOT more exacting.
>
> I have not looked at looked at you new stuff yet. I picked a cvs tree
> from a few weeks ago as my target to study. Trying to optimize changing
> source in a new lang was pretty challenging. So, I decided to just pick
> a release a work with it. I'll take a look tonight--sounds like you have
> made some pretty significant changes.
oh my yes - in the last 2 weeks I've probably swapped out/around 1000
lines of code or so.
Please take a look. Significant code:
yum-HEAD/yum/config.py
repos.py
failover.py
yum-HEAD/rpmUtils/updates.py
tests/test.py (should be a unittest for updates class)
arch.py - most is from rhpl but I added a number of
functions
> http://www.python.org/doc/current/lib/module-signal.html
>
> Bullet point 2 states that there is no signal block in python.
>
> While bullet point 3 two it states that external c functions are handled
> as atomic units. Thus a signal sent during function execution would not
> be handled until after the function as returned.
>
> Also looking at the rpm source, a KILL SIGNAL trap is used before
> manipulating the rpmdb.
>
> Thus, the function rpmlib calls (via the rpm-python) should be safe from
> being killed at an inopportune moment...
>
> If the above is true, I don't under stand why I thought I mangled my
> rpmdb last week while test ctrl-c kills
I'm not sure of all the details here either. However, I think talking to
jbj about the signal trapping would be useful. he's normally on #rpm on
freenode.
-sv
