[Yum-devel] [PATCH] Exceptions in depsolve.py (3_2_X branch, CentOS 5.4 installer)

James Antill james at fedoraproject.org
Thu Nov 12 21:26:43 UTC 2009


On Thu, 2009-11-12 at 15:33 -0500, Charlie Brady wrote:
> On Thu, 12 Nov 2009, James Antill wrote:
> 
> > On Thu, 2009-11-12 at 11:20 -0500, Charlie Brady wrote:
> >> On Thu, 12 Nov 2009, James Antill wrote:
> >>
> >>> On Wed, 2009-11-11 at 18:29 -0500, Charlie Brady wrote:
> >>>> --- depsolve.py.orig	2009-11-10 18:26:41.435910000 -0500
> >>>> +++ depsolve.py	2009-11-11 17:49:51.514498000 -0500
> >>>> @@ -1100,8 +1100,8 @@
> >>>>                       pkgresults[po] -= 1024
> >>>>
> >>>>                   obsoleted = False
> >>>> -                poprovtup = (po.name, 'EQ', (po.epoch, po.ver, po.release))
> >>>> -                if nextpo.inPrcoRange('obsoletes', poprovtup):
> >>>> +                poprovtup = (po.name, 'EQ', (po.epoch, po.version, po.release))
> >>>> +                if nextpo.po.inPrcoRange('obsoletes', poprovtup):
> >>>
> >>> The actual bug here would be a higher caller putting a txmbr into the
> >>> list of things to compare_providers.
> >>
> >> Aren't there two bugs? .ver member on po, and .inPrcoRange on nextpo?
> >
> > .ver will be == .version for any yum object above YumAvailablePackage.
> 
> Not in this case, .ver doesn't exist, hence the exception. 
> IIRC, po is an instance of PackageObject, and PackageObject doesn't have 
> .ver.

 How can po be a PackageObject? I find it really unlikely, and having a
quick look in the rhel5-base branch of anaconda I don't see how that
could happen. Anaconda isn't creating any PackageObject's by hand, and
yum doesn't use that class directly.

> > AFAIK the only bug is that nextpo is a TransactionMember and not a
> > PackageObject.
> 
> That is the second bug.
> 
> > This is a really old anaconda that has it's own reolveDeps/tsCheck
> > (this is RHEL-5 anaconda, I assume?)
> 
> Correct.
> 
> > To debug this you need to find out how the wrong objects are getting
> > into that list in anaconda, AFAIK the patch you posted shouldn't change
> > anything ... but I'm not a real anaconda developer.
> 
> I think it's reasonable to assume that someone here is an anaconda 
> developer

 AFAIK none of the main anaconda developers are on this list. Although
I'm not sure how much help you'll get for the RHEL-5 version of
anaconda, on the anaconda ML.

> , and cares about anaconda/yum for RHEL5.

 Sure.

>  I can provide further 
> details if required. I'm a bit reluctant to open a bug in 
> bugzilla.redhat.com, because I'm not installing vanilla RHEL5. But I'm 
> fairly sure that the bug is latent in RHEL5, and not caused by me.

 I see this on 393, in the rhel5-base branch:

                if self.tsInfo.exists(dep.pkgtup):
                    pkgs = self.tsInfo.getMembers(pkgtup=dep.pkgtup)
                    member = self.bestPackagesFromList(pkgs)[0]

...which is wrong (getMembers() returns txmbrs, not pkgs) and looks like
the traceback you have.
 I'm not 100% sure that's the exact version in RHEL-5.4 though, and this
will only trigger if the yum that anaconda is using is the RHEL-5.4
(maybe 5.3) version ... and I'm not even sure they update the yum
version there for the RHEL-5 installs.
 But feel free to open a BZ.



More information about the Yum-devel mailing list