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.
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.
FS#30179 - pacman refuses to overwrite nonempty directory with file, yet commits transaction
Attached to Project:
Pacman
Opened by Gaetan Bisson (vesath) - Thursday, 07 June 2012, 15:26 GMT
Last edited by Allan McRae (Allan) - Sunday, 24 February 2013, 03:13 GMT
Opened by Gaetan Bisson (vesath) - Thursday, 07 June 2012, 15:26 GMT
Last edited by Allan McRae (Allan) - Sunday, 24 February 2013, 03:13 GMT
|
DetailsSay your disk has a file called /var/run/bla, and some "filesystem" package contains a symlink called /var/run; pacman --force will refuse to install it, but will still update the database like it happened.
Live example: # pacman -S filesystem --force resolving dependencies... looking for inter-conflicts... Targets (1): filesystem-2012.6-2 Total Installed Size: 0.30 MiB Net Upgrade Size: 0.23 MiB Proceed with installation? [Y/n] y (1/1) checking package integrity [#####################################] 100% (1/1) loading package files [#####################################] 100% (1/1) checking available disk space [#####################################] 100% (1/1) upgrading filesystem [#####################################] 100% warning: directory permissions differ on sys/ filesystem: 755 package: 555 error: extract: not overwriting dir with file var/run error: problem occurred while upgrading filesystem error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded. # pacman -Q filesystem filesystem 2012.6-2 # ls -la /var | grep run lrwxrwxrwx 1 root root 11 Jun 6 10:13 lock -> ../run/lock drwxr-xr-x 4 root root 72 Jun 6 11:47 run For context, see: https://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023067.html |
This task depends upon
Closed by Allan McRae (Allan)
Sunday, 24 February 2013, 03:13 GMT
Reason for closing: Fixed
Additional comments about closing: git commit 34749e17
Sunday, 24 February 2013, 03:13 GMT
Reason for closing: Fixed
Additional comments about closing: git commit 34749e17
BTW, --force is not needed to get this.
We know the bug exists. We know what the problem is.
> pacman -U foo-1-2-any.pkg.tar.xz
loading packages...
resolving dependencies...
looking for inter-conflicts...
Packages (1): foo-1-2
Total Installed Size: 0.00 MiB
Net Upgrade Size: 0.00 MiB
Proceed with installation? [Y/n]
(1/1) checking keys in keyring [######################] 100%
(1/1) checking package integrity [######################] 100%
(1/1) loading package files [######################] 100%
(1/1) checking for file conflicts [######################] 100%
error: failed to commit transaction (conflicting files)
foo: /foo exists in filesystem
Errors occurred, no packages were upgraded.
> pacman -U --force foo-1-2-any.pkg.tar.xz
loading packages...
resolving dependencies...
looking for inter-conflicts...
Packages (1): foo-1-2
Total Installed Size: 0.00 MiB
Net Upgrade Size: 0.00 MiB
Proceed with installation? [Y/n]
(1/1) checking keys in keyring [############################] 100%
(1/1) checking package integrity [############################] 100%
(1/1) loading package files [############################] 100%
(1/1) upgrading foo [############################] 100%
error: extract: not overwriting dir with file foo
error: problem occurred while upgrading foo
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.
We will never delete files, even with --force, so if the conflict is a directory being replaced with a file, we should still abort and the user can manually delete the folder to get around the conflict. Or should we assume force means we have to delete the folder?
https://mailman.archlinux.org/pipermail/pacman-dev/2013-February/016450.html