[Yum-devel] [PATCH/RFC] What to do if a plugin fails to load?
jantill at redhat.com
Wed Jun 13 19:59:36 UTC 2007
On Wed, 2007-06-13 at 15:15 -0400, Jeremy Katz wrote:
> On Wed, 2007-06-13 at 14:52 -0400, Matthew Miller wrote:
> > On Wed, Jun 13, 2007 at 02:43:13PM -0400, Jeremy Katz wrote:
> > > In some cases (especially on distro upgrades where you have to do
> > > further updates after the fact), loading plugins can fail to load for
> > > various reasons. We should probably be tolerant of that and just not
> > > load them. What do people think of the attached?
> > Not to make things more difficult, but some plugins may be more vital than
> > others -- in some cases, running with a plugin disabled may really screw up
> > the system. (For example, protectbase.)
> Yeah, that's what makes things hard... but blowing up with a traceback
> of ImportError is almost certainly the wrong failure mode.
Personally, I can't think of any major cases where a plugin is going
to be so important that it's better to not run yum at all.
Even when you have edge cases like yum-security is broken, it's almost
certainly better to have "yum --security update -y" do a full update in
than to just fail and do nothing, even if it has a good error message.
> > How about making "failure mode" a
> > standard configuration option in the conf file for each plugin?
> And then you get to "what if reading the conf file fails"?
> Realistically, we just need to decide on a line and stick to it. Either
> a) Failure to load a plugin just disables the plugin
> b) Failure to load a plugin aborts with a nice-ish error message
> My patch is the former, partially because it's the easier thing to
> implement but also because getting out of the latter case is still not
> obvious or simple for end-users.
The obvious candidate, for the second approach, would be something
module = imp.load_module(modname, fp, pathname, description)
+ except ImportError:
+ raise PluginYumExit('"%s" plugin failed to load; use --noplugins' % modname)
...but as I said, I think your approach is better.
 In theory it might be better to abort immediately, for query
yum --security list updates
...which is done on the cmd line, but even then it's fairly easy to see
what's gone wrong ... and someone running that from cron just before an
update will likely disagree.
James Antill <jantill at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.baseurl.org/pipermail/yum-devel/attachments/20070613/25c20ed5/attachment.pgp
More information about the Yum-devel