Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#3492 - pacman -U doesnt honour 'provides' or 'replaces'

Attached to Project: Pacman
Opened by Vinay S Shastry (shastry) - Wednesday, 16 November 2005, 11:47 GMT
Last edited by Xavier (shining) - Tuesday, 15 September 2009, 10:05 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Medium
Priority Normal
Reported Version 0.7 Wombat
Due in Version 3.4.0
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

I tried installing a package from AUR http://aur.archlinux.org/packages/gtk-engines-cvs/gtk-engines-cvs/PKGBUILD . The pkgbuild is fine, but when i try installing it,

pacman -U gtk-engines-cvs-051116-1.pkg.tar.gz
loading package data... done.
:: gtk-engines-cvs conflicts with gtk-engines. Remove gtk-engines? [Y/n]
error: this will break the following dependencies:
gtk-engines: is required by gnome-themes-extras
gtk-engines: is required by gnome-themes

I think this is a pacman bug because it doesnt seem to check/honour the 'provides' or 'replaces' values.

To install this.. i had to remove gtk-engines with --nodeps and then install this.
And i believe this is not limited to this package alone.
This task depends upon

This task blocks these from closing
 FS#5798 - --syncdeps option for -A/-U 
Closed by  Xavier (shining)
Tuesday, 15 September 2009, 10:05 GMT
Reason for closing:  Fixed
Additional comments about closing:  after 4 years, this is fixed, thanks to Nagy, woohoo :) commit 0da96abc90
Comment by Mark Rosenstand (bitbull) - Monday, 28 November 2005, 03:30 GMT
I believe the proper fix to this would be to not ask whether to remove the conflicting package. It seems to confuse a lot of people (see the ml) and when you consider the functionality to the amount of additional code (and hence the maintainability and complexity of pacman), it can't really be justified.
Comment by Judd Vinet (judd) - Monday, 28 November 2005, 19:23 GMT
Yea, I know about this one. It has to do with the vast differences between an --upgrade and a --sync operation in pacman's code.

The difference is smaller in the libpacman code, so we should be able to fix this issue in libpacman.
Comment by Vinay S Shastry (shastry) - Tuesday, 29 November 2005, 01:31 GMT
offtopic a bit: is there any roadmap/release schedule for libpacman ?
Comment by Miklos Vajna (vmiklos) - Monday, 02 January 2006, 17:53 GMT
see http://www.archlinux.org/pipermail/pacman-dev/2005-October/000017.html
Comment by Dan McGee (toofishes) - Wednesday, 31 January 2007, 02:24 GMT
This bug is going to take a little overhaul of the internal pacman structure to fix. Currently, the add/upgrade and sync code are still different. For now, the best resolution is to force uninstall, and then install the replacement package. This should get fixed somewhere around pacman 3.1 when we try and merge parts of the upgrade and sync code.
Comment by Nagy Gabor (combo) - Wednesday, 09 January 2008, 13:18 GMT
"For now, the best resolution is to force uninstall, and then install the replacement package."
-Rd is not safe even if you install the replacement package later.

Hopefully sync.c will be cleaned-up soon (to 3.2), so then we can use its power to manage all the transaction types.
See also: http://www.archlinux.org/pipermail/pacman-dev/2007-September/009474.html
Comment by Xavier (shining) - Thursday, 09 July 2009, 11:29 GMT
This is fixed in Nagy universal branch : http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/universal
but this will be post 3.3.

Loading...