[Yum-devel] API Changes: Was: plugings modifying the URLGrabber instance

[seth vidal]

On Thu, 2005-06-30 at 16:51 -0400, Jack Neely wrote: 
> > 
> > So let's talk about repos and making a sensible rhn-repo type.
> > Here are the methods of yum.repos.Repository the class that represents a
> > single repository:
> 
> Okay, just note that I'm sort of poking at this from two directions.
> Making Yum speak RHN, and adding features to Yum so that RHN/Current
> could be modified to work with Yum.

So one thing I'm not interested in - I'm not interested in yum emulating
or talking over xml-rpc just like up2date/rhnsd does.

I wouldn't mind learning from problems they may have encountered but
making yum compatible with rhn's xml-rpc command stack is NOT terribly
interesting to me.
I can see how it might be valuable to be able to, eventually, but
targeting that first is a bad idea, imo.


> And generalized.
> 
> > 
> > I guess this is really how we start cleaning up the api.
> > 
> 
> Yeah, lets start with some cleaning up of the API and object code.  What
> I find confusing is that both PackageObjects and PackageSacks are
> inherited, changed, inherited, overrided, etc.  And from what I
> understand (which may be very wrong) it looks like that Yum can only use
> one type of PackageSack.  (Either you use the SQL caching sack or not.)

And mentioned on the YumIdeas wiki page - reducing the duplication and
complexity in repomd and packages.py.


> If that's mostly correct, let generalize PackageSack so its always the
> same object.

Well we need a few types of packageSacks just to take advantage of some
of the features without things getting silly:

ListPackageSack is handy - stuff a sack full of packages and run the
method of PackageSacke on that set of packages. It's used all the time
to simplify operations on a bunch of packages, Especially sorting.


> Each repo type needs to proivde its own PackageObject that
> is inheritied from the right one in Yum, and lets create a Repository
> class for each repo type.

We need a couple types of packageobjects, I think, though. one based
from packages using a ts to access them and one getting data from a
remote source.

We could combine them to some extent but I think we'd see very few
shared methods.
Something like:
YumPackageObject
    YumRepoMDPackageObject
    YumRHNPackageObject
    YumInstalledPackageObject
       YumLocalPackageObject
    YumSomeArbitraryPackageObject


Then we would have for repos:
YumRepo
  YumRepoMDRepo
  YumRHNRepo
  YumFooRepo



And for packageSacks we'd end up with:
PackageSack
    RepoMDPackageSack
    SQLitePackageSack
    ListPackageSack
    RHNPackageSack


Then from what I've heard vaguely from Paul today we might need:
YumConfigStructure
    YumConfigParserConfig
    AnacondaConfig
    

That seem like where we need to head?