[Yum-devel] [PATCH 2/3] Add argument 'errorfunc' to _getFile and getPackage.

James Antill james at fedoraproject.org
Tue Jan 10 20:46:21 UTC 2012


On Wed, 2012-01-04 at 10:45 -0500, Zdenek Pavlas wrote:
> > >      def _getFile(self, url=None, relative=None, local=None,
> > > ...
> > > -            cache=True, size=None):
> > > +            cache=True, size=None, errorfunc=None):
> > 
> >  Just a minor thing, but this will break rhn-plugin ...
> 
> Uh, really, this raises TypeError :(
> Always amazed how simple things turn out to be complex.

 Yeh, having no API would be much nicer a lot of the time :).

> > so can you open a  BZ for them to add this arg?
> 
> It's not enough to just add an arg.  The caller expects that
> errorfunc is called on failures instead of raising an exception.

 That's what I meant by you probably not being able to just open the BZ
and add a conflict ... and then forget about it.

> This requires wrapping whole RhnRepo._getFile(), and the wrapper
> does not have to be in the same class..  I think it's better to
> do that in yum:

 This wrapping is pretty gross, from an implementation POV; the fact
we'll have two different code paths (one of which will almost never get
tested); and the fact that when the argument "is there" we have an
async. call but when we wrap it we'll get a sync. call.
 Much better options are:

1. Find some way to make it not break, likely splitting _getFile() up so
that rhnplugin/whatever can override the bits it needs to (and make that
a "public" API). This seems like pain, and we've all thought just
waiting for RHN to die might be a lot easier :).

2. Just note that it'll break, add the conflicts and make sure rhnplugin
unbreaks it correctly (I'm assuming we'll ignore the RHN re-connection
logic here, as a sync. problem, and treat it as really heavy setup).

3. Have some kind of repo. attribute that says if the repo. can do
async. calls ... and then have those go through a sync. call stack. This
means we'll still have the problem of "nobody will be testing the RHN
code path" ... but at least it won't have the other problems (I think we
can get away with this now).



More information about the Yum-devel mailing list