FS#12293 - When replacing packages pacman removes old packages before checking file conflicts

Attached to Project: Pacman
Opened by Andrew Eikum (ColdPie) - Sunday, 30 November 2008, 21:18 GMT
Last edited by Dan McGee (toofishes) - Monday, 13 April 2009, 15:08 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 3.2.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

A package upgrade today said to replace esd with extra/esound. After downloading all of the packages, it removed esd as expected. After removing the old package, it checked for file conflits, and found a conflict in catalyst-utils, which caused no packages to be upgraded. Since the new esound package was not installed, it doesn't seem right that the old esd package (which was intended to be replaced) should remain removed -- my system is now missing a package. Thankfully it printed a warning about one of the config files moving, otherwise it likely would've slipped under the radar.

Attached is pacman output from the failed upgrade.
   pacman-esd-log (3.7 KiB)
This task depends upon

Closed by  Dan McGee (toofishes)
Monday, 13 April 2009, 15:08 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#9088 
Comment by Dan McGee (toofishes) - Sunday, 30 November 2008, 21:51 GMT
Depends a lot on a true transaction system, which is covered in FS#8585 and FS#9694. Until then, I'm not sure what all we can do here unless there is some code reordering that can be done to fix this problem. I worry that might just introduce other problems.
Comment by Xavier (shining) - Monday, 01 December 2008, 09:12 GMT
dup of  FS#9088  ?
Comment by Dan McGee (toofishes) - Monday, 01 December 2008, 13:09 GMT
Yes, looks like it. Unfortunately no one has really made any headway on fixing this issue.
Comment by Allan McRae (Allan) - Tuesday, 02 December 2008, 03:13 GMT
I was just going to look into this because I similarly ended up with no gnome-network-manager/network-manager-applet...

I don't know that part of the code that well, but can we just schedule the actual removal for after the conflict checking? It would require conflict checking to know what files were belonging to the removed packages.
Comment by Dan McGee (toofishes) - Tuesday, 02 December 2008, 03:25 GMT
Yeah, for some reason I'm thinking rescheduling these things is not as easy as it seems, but I can't verify that right now.

Loading...