[Yum-devel] [PATCH] Avoid dangling iterators if auto_close is used

Panu Matilainen pmatilai at laiskiainen.org
Mon Feb 14 15:15:08 UTC 2011


On 02/14/2011 04:31 PM, James Antill wrote:
> On Sun, 2011-02-13 at 16:51 +0200, Panu Matilainen wrote:
>> On Fri, 11 Feb 2011, James Antill wrote:
>>>
>>> Gah, another reason to hate auto_close ... ACK.
>>> Can you add a comment to the ts.close() calls though, saying something
>>> like "note all 'mi' have to be gone when we call this" or something.
>>
>> Here's an alternative approach you might find more attractive, as instead
>> of adding yet more cruft it:
>> - hides away auto_close inside a single function
>> - eliminates the dangling iterator issue
>> - removes code duplication by handling gpg-pubkey filtering centrally
>> - should be compatible with all historical rpm brokenness in this area
>
>   ACK, for the code. Although the indentation seems weird in a few places
> (Eg. _all_packages() doesn't look like it should need -+ lines).

The patch seems to have gotten a bit mangled by email, sorry about that. 
The _all_packages() part seems a bit funny because _get_packages() does 
pretty much what _all_packages() used to do, and now _all_packages 
simply becomes a call to _get_packages() with no arguments.

Anyway, the patch wasn't really intended for submission as-is but more 
to get a "preliminary ack" on the idea. With the ack gotten, I'll polish 
it up a bit (at least the *args, **kwds argument shuffle for dbMatch() 
is uuuuugly)

>> _header_from_index() could be converted to use this too, but if it's
>> expected to return headers for gpg-pubkeys too then _get_packages() will
>> need a switch to enable/disable the filtering.
>
>   That should be fine, although _header_from_index() is a dead function
> anyway. As long as returnGPGPubkeyPackages works, it's all good :).

Is there a reason to actually keep it around since it's dead and 
apparently an internal-only function at that? I can update that part 
too, but I prefer removing dead code to patching it :)

	- Panu -


More information about the Yum-devel mailing list