[Yum-devel] yum api thoughts

seth vidal skvidal at phy.duke.edu
Sat Dec 3 17:13:37 UTC 2005


been looking at all of the methods that float off of YumBase and trying
to remove some of the unnecessary ones or ones that have been used in a
single location.

items removed so far:
sortPkgObj() - just silly - put it in yum.misc
excludeCompatArchs() - it's used in one place and it boils down to a
single line - kill it


things that need some love:
 We have no fewer than 4 methods that ultimately do the same thing

- whatProvides()
- findDeps() - wrapper to whatProvides that reports all the deps and
potential solutions to a list of packages
- returnPackagesByDep() - takes a depstring direct from rpm and runs
whatProvides on it (quasi-usefully raising more exceptions if the
strings are screwed up)
- returnPackageByDep() - just a wrapper around returnPackagesByDep()
which reduces the pkgs out to a single, best package.

It seems like returnPackageByDep() is quasi useful as it reduces out the
other packages. But returnPackagesByDep() isn't all that useful it might
make more sense to add the depstring parsing capabilities to
whatProvides() and/or a simple function to handle the depstring parsing
before handing that to whatProvides()

Looking back on findDeps() I'm having trouble figuring out why it's not
just in the calling function in cli.py and no where else. It's not even
used in yum-utils.

We also have searchPackageProvides() which is doing something markedly
similar to the above.


Right now we have a lot of methods off of YumBase and a large number of
them seem silly. Things we have:
  - do*Setup() methods
  - package downloading/verifying methods
  - ts interaction methods
  - depsolving methods
  - cleaning methods
  - group interaction methods

I was thinking that maybe it's worth:
 1. reducing down the setup functions - maybe making doConfigSetup()
happen when you create the yum base object.
 2. seeing if it is possible/reasonable for the PackageObjects to carry
around their own downloading/verification methods
 3. looking for functions that are only ever used once in yum in finding
out if we
need them at all.
 4. reducing the number of 'resolve this dep but provide me the output
in this way' functions and/or make sure they're all acting the same way.

I think it would make the yum modules easier to program for if there
were fewer and less involved methods that are suspiciously similarly
named to go through. However, I have much less experience designing a
programming interface than a lot of folks here and I'd like to hear what
things I'm doing wrong or wrong assumptions I'm making.

Thanks,
-sv







More information about the Yum-devel mailing list