[Yum-devel] A new ctrl-c gotcha/regression

Panu Matilainen pmatilai at laiskiainen.org
Mon Feb 14 19:47:54 UTC 2011


On 02/14/2011 07:42 PM, seth vidal wrote:
> On Mon, 2011-02-14 at 19:40 +0200, Panu Matilainen wrote:
>> On 02/14/2011 07:07 PM, James Antill wrote:
>>> On Mon, 2011-02-14 at 18:37 +0200, Panu Matilainen wrote:
>>>> Spotted while looking at something related: commit
>>>> e95f16d8342bc4dcdfde6b8858a8704bc4c1bdf8 causes yum to hold the rpmdb
>>>> open throughout the remaing package downloads after first signature
>>>> check happens. Which wont exactly help catching ctrl-c in timely manner...
>>>
>>>    Blah. We should have thought thought of that, of course it doesn't help
>>> that C-c has been semi-broken for a while now (and it won't trigger on
>>> rawhide due to no sig checks -- AFAIK this code is only in rawhide, or
>>> the rawhide rebuild repos).
>>>
>>>> Perhaps the simplest bandaid would be adding an optional argument
>>>> sigCheckPkg() to automatically nuke the ts after checking and use it for
>>>> the call from within downloadPkgs(). The downside of this is that it'll
>>>> cause a bunch of rpmdb re-re-re-opens, depending on the number of repos
>>>> and their config. There's no helping that with rpm 4.4.x, but with>=
>>>> 4.6.x rpm doesn't actually need the database for signature checking, it
>>>> uses an in-memory keyring which is only initially populated from the
>>>> database.
>>>
>>>    Yeh, it's probably not worth it ... no sane person has more than 10
>>> repos. which downloaded packages have come from, so I bet it's just
>>> noise even in 4.4.x (and this feature is unlikely to get into RHEL-5
>>> anyway).
>>>
>>>    Another thought, given that, how bad is it to just always nuke to ts on
>>> 4.6.x+?
>>
>> You certainly don't want to nuke the entire ts for each individual
>> signature check, as it'd result in rpmdb open+close for every single
>> package in the transaction. Once per-repo would be "bad enough" (if
>> bearable) already, especially since its technically completely unnecessary.
>>
>> Basically the trick with newer rpms is to keep the actual ts, but just
>> call ts.closeDB() on it once the keyring is loaded. No rocket science,
>> I'm just trying to figure out how best fit it into the yum ecosystem.
>>
>
> /me adds another item in favor of detached sigs and/or x509 sigs instead
> of going through rpm for all of it.

Oh, perhaps I should elaborate a bit. The above probably sounds like 
nasty black magic, which is kinda is: it's a trick to allow signature 
checking without holding open rpmdb on versions where there are no 
python bindings for the rpm in-memory keyring.

If we forget about rpm 4.6 - 4.7 (ie just let them behave like 4.4.x 
does), in newer versions you can use your own keyring without ever 
touching the rpmdb for keys if you want to - for example pulling the 
keys pointed to by .repo files into a keyring and telling rpm to use 
that instead of what might be in the rpmdb. It's just that wedging this 
kind of new stuff into yum while maintaining yum's api compatibility, 
rpm 4.4.x compatibility and without adding large sections of differing 
codepaths causing even more pain, is not always exactly trivial.

If it wasn't clear, I'm looking into various ways to make rpm within yum 
less painful than it currently (rather obviously) is, not more :)

	- Panu -


More information about the Yum-devel mailing list