[arch-general] pacman bug? (can't replace dir with file)
Is this a known pacman bug (or a feature)? I tried to upgrade python-fuse and it errored out. /usr/lib/python2.6/site-packages/fuse_python-0.2-py2.6.egg-info is a directory in the old package, but a file in the new package. # pacman -S python-fuse resolving dependencies... looking for inter-conflicts... Targets (1): python-fuse-20090321-1 Total Download Size: 0,00 MB Total Installed Size: 0,15 MB Proceed with installation? [Y/n] checking package integrity... (1/1) checking for file conflicts [#####################################################] 100% error: could not prepare transaction error: failed to commit transaction (conflicting files) python-fuse: /usr/lib/python2.6/site-packages/fuse_python-0.2-py2.6.egg-info exists in filesystem Errors occurred, no packages were upgraded. -- damjan
On Sun, Mar 22, 2009 at 4:52 PM, Damjan Georgievski <gdamjan@gmail.com> wrote:
Is this a known pacman bug (or a feature)? I tried to upgrade python-fuse and it errored out. /usr/lib/python2.6/site-packages/fuse_python-0.2-py2.6.egg-info is a directory in the old package, but a file in the new package.
# pacman -S python-fuse resolving dependencies... looking for inter-conflicts...
Targets (1): python-fuse-20090321-1
Total Download Size: 0,00 MB Total Installed Size: 0,15 MB
Proceed with installation? [Y/n] checking package integrity... (1/1) checking for file conflicts [#####################################################] 100% error: could not prepare transaction error: failed to commit transaction (conflicting files) python-fuse: /usr/lib/python2.6/site-packages/fuse_python-0.2-py2.6.egg-info exists in filesystem Errors occurred, no packages were upgraded.
Hmm, I'd suggest making a simple test package that just does "mkdir /foobar" in the build function, then bumping the version and replacing it with a file.
Hmm, I'd suggest making a simple test package that just does "mkdir /foobar" in the build function, then bumping the version and replacing it with a file.
Confirmed, should I open a bug for this? root# pacman -U test-1.0.1-1-i686.pkg.tar.gz loading package data... checking dependencies... (1/1) checking for file conflicts [#####################################################] 100% error: failed to prepare transaction (conflicting files) test: /test exists in filesystem errors occurred, no packages were upgraded. Here's the PKGBUILD I created: pkgname=test pkgver=1.0.0 pkgrel=1 pkgdesc='Test Package' arch=('i686' 'x86_64') url="" license=('GPL') depends=() source=() md5sums=() build() { mkdir ${pkgdir}/${pkgname} } Here's the diff to the updated package: --- PKGBUILD 2009-03-23 19:05:49.000000000 +0100 +++ PKGBUILD.1 2009-03-23 19:05:56.000000000 +0100 @@ -1,6 +1,6 @@ pkgname=test -pkgver=1.0.0 +pkgver=1.0.1 pkgrel=1 pkgdesc='Test Package' arch=('i686' 'x86_64') @@ -11,5 +11,5 @@ md5sums=() build() { - mkdir ${pkgdir}/${pkgname} + touch ${pkgdir}/${pkgname} } -- damjan
On Mon, Mar 23, 2009 at 1:08 PM, Damjan Georgievski <gdamjan@gmail.com> wrote:
Hmm, I'd suggest making a simple test package that just does "mkdir /foobar" in the build function, then bumping the version and replacing it with a file.
Confirmed, should I open a bug for this?
Yup. Make sure you stick it in the "Pacman" section :)
On Mon, 2009-03-23 at 19:08 +0100, Damjan Georgievski wrote:
error: failed to prepare transaction (conflicting files) test: /test exists in filesystem
I think it has to do something with this: [jan@server ~]$ pacman -Qo /usr/share/vte error: cannot determine ownership of a directory The point with directories is that there's no real ownership, as lots of packages can store files in such a location. Now, what would have happened if your directory on the filesystem contained files not belonging to the package that is upgraded?
Is this a known pacman bug (or a feature)? I tried to upgrade python-fuse and it errored out. /usr/lib/python2.6/site-packages/fuse_python-0.2-py2.6.egg-info is a directory in the old package, but a file in the new package.
http://bugs.archlinux.org/task/13932 -- damjan
On Mon, Mar 23, 2009 at 1:30 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Mon, 2009-03-23 at 19:08 +0100, Damjan Georgievski wrote:
error: failed to prepare transaction (conflicting files) test: /test exists in filesystem
I think it has to do something with this: [jan@server ~]$ pacman -Qo /usr/share/vte error: cannot determine ownership of a directory
The point with directories is that there's no real ownership, as lots of packages can store files in such a location. Now, what would have happened if your directory on the filesystem contained files not belonging to the package that is upgraded?
True, but pacman should probably check to see if the dir is empty, and replace it if it is. I wonder what would happen in the case of: packageA: /foo/bar normal file packageB: /foo/bar/baz normal file With packageA installed, attempting to install packageB. I'd hope it would error out somehow
Aaron Griffin wrote:
On Mon, Mar 23, 2009 at 1:30 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Mon, 2009-03-23 at 19:08 +0100, Damjan Georgievski wrote:
error: failed to prepare transaction (conflicting files) test: /test exists in filesystem I think it has to do something with this: [jan@server ~]$ pacman -Qo /usr/share/vte error: cannot determine ownership of a directory
The point with directories is that there's no real ownership, as lots of packages can store files in such a location. Now, what would have happened if your directory on the filesystem contained files not belonging to the package that is upgraded?
True, but pacman should probably check to see if the dir is empty, and replace it if it is.
That seems like something dangerous to do, what if package A installed for example, /var/lock/mysoftware/ to keep locks for multiple purposes, and you install package B, which replaces /var/lock/mysoftware/ with a file called /var/lock/mysoftware (because /var/lock/mysofware/ happens to be empty at that point), causing package A to break. Not only does it give the potential to break software (bad) instead of erroring out (good), it gives inconsistent results across multiple systems. I wonder what would happen in the case of:
packageA: /foo/bar normal file packageB: /foo/bar/baz normal file
With packageA installed, attempting to install packageB. I'd hope it would error out somehow
On Sat, Mar 28, 2009 at 04:12, RedShift <redshift@pandora.be> wrote:
That seems like something dangerous to do, what if package A installed for example, /var/lock/mysoftware/ to keep locks for multiple purposes, and you install package B, which replaces /var/lock/mysoftware/ with a file called /var/lock/mysoftware (because /var/lock/mysofware/ happens to be empty at that point), causing package A to break.
Not only does it give the potential to break software (bad) instead of erroring out (good), it gives inconsistent results across multiple systems.
Agreed.
participants (5)
-
Aaron Griffin
-
Daenyth Blank
-
Damjan Georgievski
-
Jan de Groot
-
RedShift