Description of problem: I am not entirely sure if this is the best description, but it appears that the following causes problems: 1. a package python23-foo at version 0.1 being upgraded to 0.2 2. 0.2 now requires python-foo 3. python-foo requires python23-foo This triggers handling in rpmts_Check() which checks the problems list for issues in the depsolve. The above scenario causes the check to parse through the pkgNEVR found in the rpmProblem structure. Currently, the code assumes that the Arch will be apart of pkgNEVR. However, in my resolve situation, it's not the case. Therefore, the returning Python object has an incorrect Release value as it is cut off. Version-Release number of selected component (if applicable): 4.4.2+ I am including a patch against current CVS. I am not aware of any cases where the Arch would leak into rpmProblem's pkgNEVR string. If there are, a further hack would have to be developed to somehow, someway, detect when an Arch is there and when it is not.
Created attachment 119663 [details] This just gets rid of the Arch parsing.
BTW, this is for rpm-python. Sorry I didn't state that first.
A better example for everyone to Grok: 1. Use yum 2.4.0 and rpm 4.4.2+. 2. Install php and php-pear. (cyclic dep) 3. Run "yum remove php-pear". 4. Then you get this nonsense: --> Processing Dependency: php-pear for package: php --> Finished Dependency Resolution Error: Requiring package php-5.0.5-3.el3 not in transaction set nor in rpmdb Implementing the attached patch, you get: --> Processing Dependency: php-pear for package: php --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package php.i386 0:5.0.5-3.el3.ch set to be erased --> Running transaction check --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-imap --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-dba --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-soap --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-devel --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-xmlrpc --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-gd --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-mbstring --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-odbc --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-xml --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-bcmath --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-pgsql --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-ldap --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-mysql --> Processing Dependency: php = 5.0.5-3.el3.ch for package: php-ncurses --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package php-pgsql.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-bcmath.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-xml.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-mysql.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-ldap.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-soap.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-xmlrpc.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-devel.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-mbstring.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-odbc.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-dba.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-ncurses.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-imap.i386 0:5.0.5-3.el3.ch set to be erased ---> Package php-gd.i386 0:5.0.5-3.el3.ch set to be erased --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: php-pear i386 5.0.5-3.el3.ch installed 1.7 M Removing for dependencies: php i386 5.0.5-3.el3.ch installed 5.6 M php-bcmath i386 5.0.5-3.el3.ch installed 28 k php-dba i386 5.0.5-3.el3.ch installed 43 k php-devel i386 5.0.5-3.el3.ch installed 1.4 M php-gd i386 5.0.5-3.el3.ch installed 303 k php-imap i386 5.0.5-3.el3.ch installed 88 k php-ldap i386 5.0.5-3.el3.ch installed 36 k php-mbstring i386 5.0.5-3.el3.ch installed 1.7 M php-mysql i386 5.0.5-3.el3.ch installed 135 k php-ncurses i386 5.0.5-3.el3.ch installed 67 k php-odbc i386 5.0.5-3.el3.ch installed 56 k php-pgsql i386 5.0.5-3.el3.ch installed 80 k php-soap i386 5.0.5-3.el3.ch installed 268 k php-xml i386 5.0.5-3.el3.ch installed 142 k php-xmlrpc i386 5.0.5-3.el3.ch installed 76 k Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 16 Package(s) Total download size: 0 Are you dumb [y/N]:
Another solution would be to check if the tokenized string is part of a set of sane archs: i386, x86_64, ia64, blah blah, before giving the last bytes of the Release string the big axe.
Why did this get reassigned to yum? It's going on inside rpm-python.
It got assigned to yum because changing the return from rpmts_Check() in rpm-python cannot be attempted without coordination from users of rpm-python like yum. Duh. Reassign to rpm when yum is prepared to deal with the change in ts.check() return.
I see no indication that yum is prepared to deal with a different return from ts.check().
Either the hoary tuple returned by rpmts_Check() needs to be changed to add an arch field, or other means need to be used to return dependency failure information through the bindings. Trimming known arch strings from the right hand side of a "NAME.ARCH" string contained in the byName field of a problem so that the overly complex tuple is returned pre-parsed to python will have failures whenever a package name happens to be called "foo.i386". All the problem strings can be accessed using a ts.problems() method immediately after ts.check(). Alternatively, complete, pre-parsed into separate fields, information is available for all dependency failures through the ts.check() callback as well. Not being able to report the arch of a dependency failure makes multilib dependency failures hard to report accurately. Since there is still no indication from python developers involved with yum that they have any interest in using 1) ts.problems() after ts.check() 2) the ts.check() callback 3) adding a arch to the existing tuple returned from ts.check() I'm going to defer this bug. The issue has been known, and I've asked for information on a solution, for over 3 years now.