Pacman

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.
Tasklist

FS#38265 - [pacman] Pacman cannot replace a directory with a symlink when replacing a package

Attached to Project: Pacman
Opened by Armin K. (Krejzi) - Tuesday, 24 December 2013, 18:21 GMT
Last edited by Allan McRae (Allan) - Tuesday, 24 December 2013, 22:30 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 4.1.2
Due in Version 4.2.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Summary isn't that good, but I'll try to explain here.

I've created a package, mesa-git which provides mesa.

So, in the package context mesa-git = mesa, and the former will cause latter to be removed when former is installed, and I should have no conflicts with any files from mesa package when I am installing mesa-git since mesa will be removed anyways.

Now, I have the following situation. lib32-mesa package from [community] symlinks license files from mesa from [extra], so that /usr/share/licenses/lib32-mesa is a symbolic link to /usr/share/licenses/mesa (well, at least should be acording to the PKGBUILD).

mesa package from [extra] installs /usr/share/licenses/mesa/LICENSE and /usr/share/licenses/lib32-mesa/LICENSE should be the same in that context.

But, since my package is named mesa-git and it replaces mesa, I've created /usr/share/licenses/mesa-git/LICENSE, which is the same file iirc, just to follow the packaging standards which say that license files go in /usr/share/licenses/$pkgname (or something like that). But in order not to break lib32-mesa symlinks, and since mesa-git provides mesa, I have created /usr/share/licenses/mesa as a symlink to /usr/share/licenses/mesa-git (just to keep symlinks from lib32-mesa (and lib32-mesa-git) valid).

This seems to me a perfectly valid thing to do and since mesa will remove /usr/share/licenses/mesa directory, the symlink should work just fine.

Now comes the trick.

Doing pacman -U on newly built packages gives:

:: mesa-git and mesa are in conflict. Remove mesa? [y/N] y
:: mesa-libgl-git and mesa-libgl are in conflict. Remove mesa-libgl? [y/N] y
:: ati-dri-git and ati-dri are in conflict. Remove ati-dri? [y/N] y
:: intel-dri-git and intel-dri are in conflict. Remove intel-dri? [y/N] y

Packages (8): ati-dri-10.0.1-1 [removal] intel-dri-10.0.1-1 [removal]
mesa-10.0.1-1 [removal] mesa-libgl-10.0.1-1 [removal]
ati-dri-git-10.1.0_devel.60267-1
intel-dri-git-10.1.0_devel.60267-1 mesa-git-10.1.0_devel.60267-1
mesa-libgl-git-10.1.0_devel.60267-1

According to this, mesa should be removed and mesa-git should be installed (as expected).

But now there is the following error:

(4/4) checking for file conflicts
[##############################################] 100%
error: failed to commit transaction (conflicting files)
mesa-git: /usr/share/licenses/mesa exists in filesystem
mesa-libgl-git: /usr/share/licenses/mesa-libgl exists in filesystem
ati-dri-git: /usr/share/licenses/ati-dri exists in filesystem
intel-dri-git: /usr/share/licenses/intel-dri exists in filesystem
Errors occurred, no packages were upgraded.

Why am I getting this? Since /usr/share/licenses/mesa is part of mesa package, which is getting removed, it shouldn't conflict at all? What am I doing wrong? This seems to me a perfectly valid thing to do, yet it doesn't work.

The bug report is about what title says, not about packaging standards so please ignore the "how the package is packaged" thing, since as I said it seems to me a perfectly valid thing to do and it doesn't work :|
This task depends upon

Closed by  Allan McRae (Allan)
Tuesday, 24 December 2013, 22:30 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixing in pacman-git (4.2)
Comment by Dave Reisner (falconindy) - Tuesday, 24 December 2013, 20:43 GMT
This behavior is by design.
Comment by Allan McRae (Allan) - Tuesday, 24 December 2013, 22:28 GMT
  • Field changed: Category (Packages: Core → Backend/Core)
  • Field changed: Reported Version ( → 4.1.2)
  • Field changed: Due in Version (Undecided → 4.2.0)
  • Field changed: Architecture (All → All)
More concise summary:

foo: directory /usr/foo
foo-git: replaces/conflicts foo, directory /usr/foo-git, symlink /usr/foo -> foo-git

Comment by Allan McRae (Allan) - Tuesday, 24 December 2013, 22:29 GMT
This has been fixed in pacman-git. pacman-4.1 is getting confused with its old behavior of handling directories and symlinks to directories.

Loading...