On 02/15/2011 06:12 PM, James Antill wrote:
On Tue, 2011-02-15 at 17:17 +0200, Panu Matilainen wrote:
On 02/15/2011 04:56 PM, James Antill wrote:
On Tue, 2011-02-15 at 11:54 +0200, Panu Matilainen wrote:
Reduces code duplication and unnecessary rpmdb reopens. The rpmdb
gets opened shortly afterwards anyway and closed before any downloads
so there should be no unwanted side-effects.
---
yum/__init__.py | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
NAK. As soon as you call rpmdb.returnGPGPubkeyPackages() then
rpmdb.returnPackages() needs to filter those "packages" out on each
call.
Hmm, so that's what the "hacky" comment referred to. I missed the
side-effect of _makePackageObject() adding them to global indexes.
OTOH having a function which should never be called seems a bit Spinal
Tap'ish to me :)
Well, the idea is that the function is only called by things like the
keys plugin ... so it can be called, but we don't want to call it in a
normal path.
Would it break the keys-remove usage (or something
else) if it returned list of RPMInstalledPackage() created objects
instead of going through _makePackageObject()?
I believe the big problem is "keys-remove", you can probably get away
with not using _makePackageObject() in returnGPGPubkeyPackages() for
list/info/etc. but removing things from the rpmdb which "aren't in" the
rpmdb is more than a little hack (having a quick look the call
dropCachedDataPostTransaction() is sure to be unhappy, although it could
be made to ignore gpg keys).
In general the fact we have the gpg "packages" is hacky, and that is
going to leak out somewhere ... so I'm not dying to change anything,
unless it's an obviously better "leak" :).
Oh, no disagreement there, the pubkey "packages" are quite a PITA. What
I'm after here is eventually shoving all the gpg-pubkey foobar into some
dark corner and deal with them there (optimally with some nice
abstraction padding added on top to hide the ugliness from callers), and
the first step of that is reducing the number of places that explicitly
deal with "gpg-pubkey" as close to one as possible.
I'll poke around some more and see what happens :)
- Panu -
- Panu -
_______________________________________________
Yum-devel mailing list
[email protected]
http://lists.baseurl.org/mailman/listinfo/yum-devel
