FS#7524 - misleading info when a versioned dep needed by another dep

Attached to Project: Pacman
Opened by Not Important (pholie) - Wednesday, 27 June 2007, 23:08 GMT
Last edited by Roman Kyrylych (Romashka) - Thursday, 28 June 2007, 08:33 GMT
Task Type Feature Request
Category General
Status Assigned
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version 3.0.5
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Summary and Info:
I tried to install a compiz-git which requires cairo. I already have cairo-lcd installed which provides and conflicts with cairo.

# pacman -S compiz-git
resolving dependencies... done.
looking for inter-conflicts...
:: cairo conflicts with cairo-lcd. Remove cairo-lcd? [Y/n] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: cairo: conflicts with cairo-lcd

pacman -Si compiz-git
Repository : compiz-fusion
Name : compiz-git
Version : 20070626-1
Groups : None
Provides : None
Depends On : mesa cairo libxml2 libxslt startup-notification libpng libxdamage libxrandr libwnck gnome-desktop control-center librsvg libxcomposite metacity
libgl
Removes : None
Conflicts With : compiz-core compiz compiz-decorator-gnome compiz-decorator-kde
Replaces : compiz-core-git compiz compiz-decorator-gnome compiz-decorator-kde
Download Size : 973.82 K
Installed Size : 4010.97 K
Description : Composite and window manager
MD5 Sum : 231b72c7e3893444238baaf5556c1470

pacman -Qi cairo-lcd
Name : cairo-lcd
Version : 1.4.6-1
URL : http://cairographics.org/
License : LGPL MPL
Groups : None
Provides : cairo
Depends On : libpng libxrender fontconfig
Removes : None
Required By : cairo-perl gtk-aqualooks-engine pango poppler
Conflicts With : cairo
Installed Size : 1342.33 K
Packager : Arch Linux (http://www.archlinux.org)
Architecture : i686
Build Date : Sat Jun 9 02:30:58 2007 UTC
Build Type : Unknown
Install Date : Wed Jun 27 22:29:39 2007 UTC
Install Reason : Explicitly installed
Install Script : No
Description : Cairo vector graphics library (with custom LCD filter)

So I couldn't figure it out why it wants to remove the cairo-lcd until I ran it with --debug.

...
debug: depcmp: cairo-lcd-1.4.6-1 ~= cairo => match
...
debug: missing dependency 'pycairo' for package 'pygtk'
...
debug: started resolving dependencies
...
debug: depcmp: cairo-lcd-1.4.6-1 >= cairo-1.4.6-2 => no match
debug: depcmp: cairo-lcd-1.4.6-1 >= cairo-1.4.6-2 => no match
...
debug: missing dependency 'cairo' for package 'pycairo'
...
debug: pulling dependency cairo (needed by pycairo)
...
debug: package 'cairo' not found in sync
debug: adding package cairo-1.4.8-2 to the transaction targets
...
...
debug: cannot find package installed 'cairo'
...
...
debug: checkconflicts: db vs target 'cairo'
debug: found conflict 'cairo' : package 'cairo'

So here it is:
# pacman -Si pycairo
Repository : current
Name : pycairo
Version : 1.4.0-2
Groups : None
Provides : None
Depends On : python>=2.5 cairo>=1.4.6-2 python-numeric>=24.2-2
Removes : None
Conflicts With : None
Replaces : None
Download Size : 31.32 K
Installed Size : 0.00 K
Description : Python bindings for the cairo graphics library
MD5 Sum : 093154b9eb145b06617e94aeeb80bf1d


The package that I want to install, compiz-git needs cairo (no matter what version), this condition is true but *also* its dependency, pycairo (not yet installed) needs cairo>=1.4.6-2 which is not installed.

So after I let it replace the conflicting package or update manually the cairo-lcd to the newest version, it installs successfully at last.

The installing process should inform which of the deps needs exactly which particular version of the package that is conflicting so one would understand better why the conflict arises.

A debug log attached in case it's needed.
This task depends upon
 FS#6508 - versioned provisions 

Comment by Not Important (pholie) - Wednesday, 27 June 2007, 23:26 GMT
the second log is actually what i wanted to post instead
Comment by Xavier (shining) - Thursday, 28 June 2007, 16:04 GMT
Ah ok, I see, it's true that pacman output is quite confusing in this case,
it would indeed be better if pacman showed that cairo-lcd doesn't provide the correct version.
Comment by Roman Kyrylych (Romashka) - Wednesday, 09 January 2008, 12:54 GMT
IIRC this is fixed in git.
Comment by Xavier (shining) - Wednesday, 09 January 2008, 13:42 GMT
I don't think so, and it doesn't look easy to fix.
The problem happens at two different steps, without any real link between them.
1) dependency resolving
Here, it realizes that cairo-lcd-1.4.6-1 doesn't match the cairo-1.4.6-2 dependency. So it pulls cairo-1.4.6-2.
2) conflicts resolving
it finds out that cairo conflicts with cairo-lcd. But we don't keep track of what pulled every package. Se we don't know that cairo was pulled because of pycairo.
Maybe we could check the dependencies again, but that would be weird. We could rather try to keep the tree of dependencies computed by checkdeps somehow, and reuse this information, as Nagy mentioned several times.

I have no idea how hard this would be however. Or maybe there is a simpler solution I don't see. So comments welcome.
Comment by Nagy Gabor (combo) - Wednesday, 09 January 2008, 13:49 GMT
Well, this is not fixed, and imho this is not a bug.

The problem is, that the installed cairo-lcd is not "good enough" to satisfy the dependency of compiz-git that's why the original cairo is pulled. But this of course conflicts with cairo-lcd which thus was selected for removal; so if user wants to keep his cairo-lcd then of course he cannot install compiz-git. (Versioned provisions can help here.)

I cannot admit that the provided info is misleading, I would say, it maybe not enough.
So we can modify the unsuccessful conflict resolving error message something like this:
If pulledpkg<->localpkg conflict wasn't resolved, we could say: "A needed dependency ('pulledpkg') conflicts with a local package ('localpkg')."
Comment by Nagy Gabor (combo) - Wednesday, 09 January 2008, 13:50 GMT
Xavier, you were faster;-) I agree with you.
Comment by Xavier (shining) - Wednesday, 16 September 2009, 12:57 GMT
When we have a conflict, are we sure its always a needed dependency vs a local package ?
Comment by Nagy Gabor (combo) - Wednesday, 16 September 2009, 22:15 GMT
No. But we have targetpkg->reason, which indicates if the package is pulled or not. Unfortunately our pmconflict_t struct just stores package names, so we lose this information. (And conflict.c should not deal with these kind of messages, it's the caller task imho.)

Of course we could change pmconflict_t struct to store pmpkg_t...
Comment by Nagy Gabor (combo) - Wednesday, 16 September 2009, 22:21 GMT
... or we could just search for conflicting package in target list ;-)

Now our conflict_check stuff is quite sophisticated, so after outerconflict call we should know that conflict->package1 is the target package.

Loading...