Re: Proposal For rpm-objects module
"Adam T. Gautier" <adam_gautier-/[email protected]> Tue, 23 Mar 2004 14:00:33 -0500
| Newsgroups | gmane.linux.redhat.rpm.python |
|---|---|
| Message-ID | <[email protected]> |
>ok so: > 1. sourceforge sucks, let's not have an cvs repository we can't get to >with any reliability. :) > > Agreed, I just don't have time to expose my internal subversion server to the Internet, just looking for a more accessible option... may not be needed. > 2. my girlfriend graduated from harvard and she said you've got no room >to look down your nose at other institutions. :) > > Your not kidding there! > 3. access to the cvs repo is doable but the current layout gets tricky >for handing out access to people I don't know.. fun huh? > > > Yeah, like I said in #1 >I think the structures look fairly good - I think you might get some >benefit by going through yum, up2date, system-config-packages and >anaconda and seeing how each handles the rpm objects - a little bit of >experience in those would help you to not make the same mistakes. > > I am doing that today... I would rather lift the code than write from scratch... >you should also be wary of how often you end up with open transaction >sets to talk to the rpmdb, some of those actions can get expensive. > > > Yeah, I was thinking that you would have one per RPMDatabase object. I assumed that you could only execute one transaction per transaction set at a time and so if you wanted to parallel say the install of some rpm files you would create multiple RPMDatabase objects that would hold their own transaction set. Still thinking about it though... >Finally, look at how the TransactionWrapper class that Adrian wrote and >I thefted from up2date works. It might be a useful base to work from for >the rpmdb class. Especially wrt VSFlags. > > > > Yes, I will defiantly look at that... Cheers, A