FS#9088 - removing packages due to conflict

Attached to Project: Pacman
Opened by Scott H (stonecrest) - Friday, 04 January 2008, 11:24 GMT
Last edited by Dan McGee (toofishes) - Saturday, 11 April 2009, 19:20 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version git
Due in Version 3.3.0
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

I was attempting to replace pacman-git with pacman (don't ask why) and had the following happen:

$ pacman -S pacman
resolving dependencies...
looking for inter-conflicts...
:: pacman conflicts with pacman-git. Remove pacman-git? [Y/n]

Remove: pacman-git

Total Removed Size: 2.25 MB

Targets: pacman-3.0.6-2

Total Download Size: 0.81 MB

Proceed with installation? [Y/n]
:: Retrieving packages from core...
pacman-3.0.6-2-i686 829.2K 547.7K/s 00:00:02 [###################] 100%
checking package integrity...
warning: /etc/pacman.d/mirrorlist saved as /etc/pacman.d/mirrorlist.pacsave
warning: /etc/pacman.conf saved as /etc/pacman.conf.pacsave
warning: /etc/makepkg.conf saved as /etc/makepkg.conf.pacsave
(1/1) checking for file conflicts [###################] 100%
error: could not prepare transaction
error: failed to commit transaction (conflicting files)
pacman: /etc/abs/abs.conf exists in filesystem
pacman: /etc/abs/supfile.community exists in filesystem
pacman: /etc/abs/supfile.core exists in filesystem
pacman: /etc/abs/supfile.extra exists in filesystem
pacman: /etc/abs/supfile.testing exists in filesystem
pacman: /etc/abs/supfile.unstable exists in filesystem
Errors occurred, no packages were upgraded.


It seems to me that a user would _STRONGLY_ prefer that the conflicted package not be removed unless pacman has a pretty damn good idea that the replacement package can be installed. It's not good when you can get left without the package you previously had or the new package - in this case pacman!

I also was surprised that, aside from the warnings about pacsave files, pacman didn't explicitly say that the conflicted package was removed.
This task depends upon

Closed by  Dan McGee (toofishes)
Saturday, 11 April 2009, 19:20 GMT
Reason for closing:  Fixed
Additional comments about closing:  Commit 391952600d30bf7c28c5403c5c9e220d345ffe87
Comment by Nagy Gabor (combo) - Friday, 04 January 2008, 17:27 GMT
Yes, this is a known problem, we have a pactest (trans001.py) for this as a reminder.
Comment by Scott H (stonecrest) - Friday, 04 January 2008, 19:15 GMT
Cool, good to know. Thanks for the info, Nagy.
Comment by Xavier (shining) - Thursday, 14 February 2008, 21:53 GMT
This may not happen often, but when it does, it usually hurts.
Also see http://bbs.archlinux.org/viewtopic.php?id=43847
The severity might be higher than medium.
Comment by Nagy Gabor (combo) - Friday, 15 February 2008, 13:00 GMT
No doubts that this is a dangerous bug, but giving higher priority to it won't help imho :-P [btw, we have the constant trans001.py reminder].

If we don't fix it immediately (I can guess, we won't...) as a hotfix we should give at least a BIG warning in this case (ie. successful remove transaction, upgrade_prepare failure => WARNING: pacman removed the following packages: ... and stopped due to an error. This is dangerous: 1. If the previous list contains essential packages (like kernel) you should try to resolve the problem before reboot. 2. You can use the testdb utility to check for broken dependencies). However, this doesn't help too much in Scott's problem.

Note: I suggested reopen  FS#9556 .

Loading...