[Yum-devel] [PATCH] Yum plugins

Menno Smits menno-yum at freshfoo.com
Fri Mar 18 23:55:29 UTC 2005


seth vidal wrote:
> 
>>When yum starts it loads plugins from /usr/lib/yum-plugins. Plugins
>>are simply Python modules. Specific functions defined within a plugin 
>>tell yum which "slots" the plugin is interested in.
> 
> 
> I'd feel a lot better if the plugins needed to be defined in a file
> in /etc as well as exist in some path. Mainly b/c it would decrease the
> possibility of someone just dropping a file in the wrong place or doing
> so maliciously.

Sounds good to me. I've mentioned at the top of plugins.py that command 
line switches to enable/disable specific or all plugins would also be a 
good idea.

We almost need a separate config file for this because plugins need to 
be initialised *before* we parse yum.conf. Or ... would could just parse 
a [plugins] section of yum.conf before plugins are loaded and then do 
the rest after.

Another problem that currently exists is that the plugins are loaded 
before the Logger instance is set up. This means all early output from 
plugins goes to stdout regardless of the log level of the message.

The following slots are currently definied:
>>- config: called before the config file is parsed. Allows the plugin
>>   to define custom config file options.
> 
> Do we need to add a plugin in the reposetup routines that possibly
> allows the user to disable repos using some other bizarro-world
> specification? As it stands there doesn't seem like there is a way to
> list other repos that are not enabled and enable them via plugins.

Yep, sounds good. I will add something like this.

> Once we hit stable we will want to make sure that the api stays fairly
> static, anyway. so if we do:
> 
> 2.3 -> devel
> 2.4 -> stable
> 2.5 -> devel
> 2.6 -> stable
> 
> Then I think we should only support an api on the stable releases,
> obviously and we should not support plugins for 2.4 on 2.6. People who
> write plugins for those versions can simply fix them/update them for the
> newer versions.
> 
> I think specifying a yum major+firstminor version number as part of the
> plugin specification would be valuable.
> 
> so we can distinguish plugins by version and ignore the right ones.

I'm fairly happy with this. It'll be interesting to see how this works 
in practice.

Menno



More information about the Yum-devel mailing list