[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