On Tue, 2003-11-11 at 11:57, David Farning wrote:
> I got yum working as a back end to redhat-config-packages yesterday--see
> screen shot below.
>
> Three considerations that would help me and others who would like to use
> yum.
>
> 1. The use of config.py. That is a pretty common module name and
> python has a very limited ability to work with two modules of the same
> name. There are a bunch of working arounds but it just seems like a
> debugging nightmare waiting to happen.
>
huh? It goes in search order. the yum path is first in the search order.
if yum were a site-package then it would just change to:
import yum
yum.config.someclass()
> 2. Several of your functions dump output to a terminal via print.
> would you consider adding a mechanism we could use to grab that output.
> Something along the lines of a progress=None added to the the function
> signature would work if followed by.
I would consider all of those places needing to die.
All the places with a sys.exit() call need to be replaced with an
exception - elliot peele did a prelim yum exception class that needs
more expansion.
> 3. I am using following method as an entry point back into yum for
> my transactionSet. Just passing (install ,filename1, filename2,
> filename3... in as cmds.
>
> clientStuff.take_action(cmds, nulist, uplist, newlist, obsoleting,
> tsInfo, HeaderInfo, rpmDBInfo, obsoleted)
>
> Now, it would be nice to be able to pass(install: filename1, remove:
> filename2, update: filename3) ;) just kidding, that RFE would take
> weeks.
it's not actually that hard - but the commandline would become a mess. I
wrote a transaction handler that takes an xml file of commands like:
remove foo
install bar
update baz
etc etc etc
and condenses them into one transaction. I don't think anyone has ever
seen that b/c it's never been finished. Other things came up. It does
work - just not the most beautiful thing.
> BTW, in the nevral.rpmnbynamearch() there is a var 'state' that seems to
> always return 'a' --unless I am smashing it somehow. What is it? I was
> hoping it was a installed flag.
a means the header is available - when you modify a transaction set it
can be in mode 'i', 'iu', 'ud', 'e' or 'a' iirc
> When creating my dataStore I am use the technique below to determine
> which packages are install and wich are not. The conditional
> if namearch in self.localHeaders.rpmbynamearch: kind or scares me as
> being pretty CPU costly. But,
> not namearch in self.newlist return that the unused kernels are
> installed. Any suggestions?
>
> for namearch in self.remoteHeaders.rpmbynamearch:
> iter = self.packageStore.append()
> ((re,rv,rr,ra,rl,ri),rs)=self.remoteHeaders.rpmbynamearch[namearch]
>
> if namearch in self.localHeaders.rpmbynamearch:
> (le,lv,lr,la,ll,li),ls)=elf.localHeaders.rpmbynamearch[namearch]
>
> self.packageStore.set(iter,
> self.COLUMN_SELECTED, gtk.FALSE,
> self.COLUMN_NAME, namearch[0],
> self.COLUMN_LVERSION, lv,
> self.COLUMN_RVERSION, rv,
> self.COLUMN_SERVER, ri,
> self.COLUMN_NAMEARCH, namearch,
> )
> else:
>
> self.packageStore.set(iter,
> self.COLUMN_SELECTED, gtk.FALSE,
> self.COLUMN_NAME, namearch[0],
> self.COLUMN_LVERSION, '',
> self.COLUMN_RVERSION, rv,
> self.COLUMN_SERVER, ri,
> self.COLUMN_NAMEARCH, namearch,
> )
I'd like to hear what you have to say about searching based on
progressively more data across the same dataset.
That is the direction I'm using to do the new metadata importing.
so you have the same data as a nevral but I want to find all things that
match
name, arch, and version - but I don't have anything else.
my thoughts were to fill in a dict with a nevra tuple that progressively
fills.
so:
dict[('name', None, None, None, None)] = [pkgobj, pkgobj]
dict[('name', None, 'version', None, None)] = [pkgobj]
so you could, theoretically, search just for name and get a dramatically
reduced set of packages to have to search.
Thoughts on other, prettier ways of doing that?
Michael and I talked about this for a while and had some ideas but
thought that the name->set of pkgs in that name might be the quickest.
-sv
