[PATCH] depsolve: avoid fragile join/split

[Dan Kenigsberg]

On Thu, Feb 20, 2014 at 09:47:00AM -0500, James Antill wrote:
> On Fri, 2014-01-31 at 10:33 +0000, Dan Kenigsberg wrote:
> > On Fri, Jan 31, 2014 at 01:34:54AM -0500, James Antill wrote:
> > > On Thu, 2014-01-30 at 09:10 +0000, Dan Kenigsberg wrote:
> > > > Currently, in a certain flow of
> > > > depsolve.Depsolve._requiringFromTransaction(), the code joins (name,
> > > > needflags, needversion) into an undelimited string, only to try to split
> > > > it back within misc.string_to_prco_tuple().
> > > > 
> > > > I would not claim that I understand the whole sequence, but please
> > > > consider taking this or something like it.
> > > 
> > >  Added something like it upstream, passes "make check" for me. If you
> > > could run it on your testcase that'd be cool (git clone, and run 
> > > "./yummain.py blah")
> > 
> > I've patched my host's yum with that patch and it works for me. Thanks!
> > 
> > Would you backport it to Fedora (19, 20) and EL6 ?
> 
>  So I got pinged by Fedora admins yesterday because mash had blown up,
> and this seems to have fixed it:
> 
> http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=5edaeb0c6379c94792cf429963fe9c94ca5d1591
> 
> ...can you confirm that your problem is still fixed now?
>

Since "my" branch is kept first on the condition, I'm not really worried.

However, I must admit that passing a string for the needversion field of
the "requirement" tuple seems like a bug that should be fixed on the
caller side.

If backward-compatibility of this function has to be maintained, calling
rpmUtils.miscutils.stringToVersion(needversion) here is more prudent
than concatanating the strings together only to reparse them within
string_to_prco_tuple(). For example, if mash sends in a needversion
string that happens to be 3 chars long, we'd get into the branch of
5edaeb0c6379c94792cf429963fe9c94ca5d1591 and explode later on, when
(reqe, reqv ,reqr) get one char each.