Bug 169998 - Upgrade of package that introduces cyclic dep causes grief in rpmts-py.c
Upgrade of package that introduces cyclic dep causes grief in rpmts-py.c
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-06 06:59 EDT by Jeff Pitman
Modified: 2014-01-21 17:52 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-24 23:36:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This just gets rid of the Arch parsing. (933 bytes, patch)
2005-10-06 06:59 EDT, Jeff Pitman
no flags Details | Diff

  None (edit)
Description Jeff Pitman 2005-10-06 06:59:59 EDT
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.
Comment 1 Jeff Pitman 2005-10-06 06:59:59 EDT
Created attachment 119663 [details]
This just gets rid of the Arch parsing.
Comment 2 Jeff Pitman 2005-10-06 07:06:18 EDT
BTW, this is for rpm-python. Sorry I didn't state that first. 
Comment 3 Jeff Pitman 2005-10-06 07:18:13 EDT
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]: 
 
Comment 4 Jeff Pitman 2005-10-06 11:11:50 EDT
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. 
Comment 5 Seth Vidal 2005-10-25 17:43:43 EDT
Why did this get reassigned to yum? It's going on inside rpm-python.
Comment 6 Jeff Johnson 2005-11-14 07:49:42 EST
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.
Comment 7 Jeff Johnson 2006-04-22 09:27:59 EDT
I see no indication that yum is prepared to deal with a different return from ts.check().
Comment 9 Jeff Johnson 2006-04-24 23:36:17 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.