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

[Menno Smits]

seth vidal wrote:

>>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.

I agree. We should aim for incremental refactoring steps that result in 
a sufficiently clean abstraction of repositories and packages so that 
talking to stuff like RHN is possible. I can envisage other repository 
types as well.

To be clear, we are aiming for Yum to be able to support different 
repository types simultaenously right?

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

I've been looking forward to this :)

>>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:

I think different package sacks are still required but Jack's right in 
that we do need some way for Yum to be able to use multiple packagesack 
types at the same time. At the moment Yum either uses the the repomd or 
the sqlite package sack. Some sort of "MetaSack" class is required to 
hold different packagesacks and aggregrate operations on them.

> 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.

I guess this is more of a (useful) special case.

> 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.

By "shared methods" I assume you mean "shared implementation". Shared 
implementation isn't as important here as shared interface. As long as 
PackageObjects look and act the same we can mix and match them 
interchangably.


> Something like:
> YumPackageObject
>     YumRepoMDPackageObject
>     YumRHNPackageObject
[snip]

These classes seem about right to me. The main thing I'd add is the 
MetaSack as mentioned above and Repository classes to abstract the 
mechanics of talking to the repository and populating package sacks or 
whatever. Hell, repository classes could probably handle parsing their 
own bits sections of yum.conf. Each repository class should have 
particular PackageObject and PackageSack subclasses associated with them.

Ideas for things to do from here (maybe this should go on the wiki?):

- merge the repomd stuff into the rest of yum and clean it up. The whole
   repomd directory can probably go unless there's still some need to
   keep it separate.

- remove the older repo packagesack stuff so that we only have the
   sqlite cache code left

- experiment with the MetaSack idea and see if its feasible to use
   multiple packagesacks at the same time

- develop a Repository base class and implement repo metadata repository
   as a subclass. This may be just refactoring what's already in
   repos.py.

Thoughts anyone? I'm sure there's plenty more to discuss.

Menno