[Yum-devel] RHN Support or Plugin Foo

seth vidal skvidal at phy.duke.edu
Thu May 5 06:36:15 UTC 2005


> Basically, we can do this:
> 
>     * Get a list of channels the machine has access to.  These are
>       equivalent to yum repositories
>     * Get last modification time for each channel
>     * list packages in channel -- we get a list that's like:
>       [name, version, release, epoch, arch, size, channel]
>     * getObsoletes()  -- same list format
>     * get the actual package (src/bin RPM)
>     * get the package header
>     * Ask the server questions, like what provides /usr/bin/foo?
>       Basically, any dependancy information RPM knows about.  You give
>       the server a list of unknowns, it returns a list of packages that
>       provide the unknowns if they exist.
> 
> > If the metadata is fairly similar then maybe some sort of generic 
> > caching API could be devised. Then the standard repo and RHN repo code 
> > could share the same caching backend.
> > 
> 
> Its probably not similar enough.  But if folks are interested in
> multiple repository types then this would be good.
> 
> > >So, let's take a step back here.  Folks are working on this idea of
> > >plugins.  Why can't we create a way to plug in alternate kinds of
> > >repositories?  The idea being that each of these plugins could provide a
> > >PackageObject and PackageSack class with a specifc API and let Yum
> > >itself combine them into a large PackageSack object.
> > 
> > This could be a reasonable idea. However it isn't really worth it if Yum 
> > only ever needs to support 2 repository types (standard yum repodata and 
> > RHN). Regardless, the refactoring I mentioned above would make this much 
> > easier to do.
> > 
> 
> I imagine if Yum starts supporting more that just one kind of repository
> support for other types would be a common
> question/demand/crackheadedidea.  *shrug*
> 
> The question really is do we want to go the plugin route for this or
> look into some code refactoring?

It's been a long time since this was posted and i've been busy doing
other stuff.

I think refactoring and abstracting to allow yum to handle other
repository types makes the most sense. It'd probably be best to extend
the repository class so it includes searching/querying of the metadata
from there. That would allow us to simply add in new classes with the
same/similar interfaces and forget about what happens underneath it.

However, I think this is not something we can undertake in the 2.3
timeline. It's probably best to work on some specific milestones for
2.4, get it finished and start breaking things in big ways for 2.5.

A new generic interface for the repository class is probably where we're
headed and we have to look into these things in the next 6 months to
deal with removeable media.

How does that sound?

-sv





More information about the Yum-devel mailing list