FS#13932 - Problem with package update that replaces directory with file

Attached to Project: Pacman
Opened by Damjan Georgievski (damjan) - Monday, 23 March 2009, 18:36 GMT
Last edited by Xavier (shining) - Tuesday, 21 July 2009, 06:56 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Xavier (shining)
Architecture All
Severity Low
Priority Normal
Reported Version 3.2.1
Due in Version 3.3.0
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Upgrading a package that replaced a directory with a file fails.

To reproduce you can create a package with the attached PKGBUILD, install it, then upgrade it with the package created from the attached PKGBUILD.new

The upgrade will fail since pacman doesn't understand that the directory created by the first package will be removed when that package is removed.
   PKGBUILD (0.2 KiB)
   PKGBUILD.new (0.2 KiB)
This task depends upon

Closed by  Xavier (shining)
Tuesday, 21 July 2009, 06:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed by commit bfd6817112b34b552e9139bdc582d048bcba38b9 (pactest is fileconflict004)
Comment by Dan McGee (toofishes) - Monday, 23 March 2009, 22:08 GMT
This should be pactest-able.

Aaron mentioned on the ML that this replacement could only take place if the directory in question is empty of all files, including those both managed and not managed by the package manager.
Comment by Philipp Brüschweiler (EdwardXXIV) - Tuesday, 21 July 2009, 00:47 GMT
I agree that the directory can't generally be replaced (if it's not empty after the removal of the old package) but I think it should be possible to give a better error message than a generic file conflict. Something along the lines of "`/etc/bla/blub' is currently a directory but mypkg-1.2-5 expects it to be a file. Please remove the old package and delete the directory before upgrading."

Loading...