rhn-applet patch [was Re: [rhn-users] up2date...]

[Bob Drzyzgula]

On Fri, Mar 19, 2004 at 06:46:22PM -0500, Daniel Veillard wrote:
> 
> On Fri, Mar 19, 2004 at 10:13:40AM -0500, Bob Drzyzgula wrote:
> > On Thu, Mar 18, 2004 at 07:31:33PM -0500, Todd Warner wrote:
> > > 
> > > Patches gladly accepted. Send 'em our way and we'll take a look-see.
> > > rhnlib and up2date are GPLed software so... there you go.
> > > 
> > > Definately sounds like something is funky though. I will make sure the
> > > right people know about it.
> > > [...]
> > 
> > rhn-applet patch:
> > [...]
> > # This patch will add support for a configurable http user agent string
> > # in the RHN toolbar applet. It relies on parallel patches to rhnlib
> > # and up2date. Affected source files are
> > #
> [...]
> > @@ -202,7 +204,8 @@
> >                                                 self.__cert__,
> >                                                 self.__proxy__,
> >                                                 self.__proxy_username__,
> > -                                               self.__proxy_password__)
> > +                                               self.__proxy_password__,
> > +                                               self.__user_agent_string__)
> >  
> 
>   Interesting but this requires first the rhnlib patch to be deployed
> unless trying a try:...except: around this call to retry with
> one less parameter in case the old API didn't got deployed yet.
> Other way is to add a Requires in the spec to the updated rhnlib version.
> 
> Daniel

Daniel,

In fact that's why I said "It relies on parallel patches
to rhnlib and up2date." :-) This part here:

+            if self.user_agent_string:
+                params.append("--userAgent")
+                params.append(self.user_agent_string)

could get you in trouble with respect to up2date unless
that package update is deployed as well.

Perhaps another way would be to increment the version
number of rhnlib with my changes (something I didn't
presume to do in an unsolicited patch :-) and rewrite
this stuff to be dependent on the value of, say,
rhn.rpclib.__version__ instead of forcing the update
in the spec file Requires or trapping an exception.

--Bob