[pacman-dev] [BUG] libalpm: symlink to directory causes conflict
Hi, this may or may not be an actual bug, I'm not sure if it's the intended behaviour. On my particular system '/lib' is a symbolic link to '/usr/lib'. I was creating a PKGBUILD for a program that places a systemd service file into '/lib/systemd/...' during installation. Unfortunately, when I would like to install the created package, libalpm detects a file conflict between '/lib' (the symlink in the filesystem) and '/lib' (the directory in the package). I skimmed through the code, and it seems '_alpm_db_find_fileconflicts()' recognizes this "conflict". Moreover, it appears that 'extract_single_file()' also cannot handle this case. Could someone confirm that this is indeed the intended behaviour? And if yes, why? Thanks, Barnabás Pőcze
On 28 Sep 2020, at 6:19 pm +0000, Barnabás Pőcze via pacman-dev wrote:
Hi,
Hello,
On my particular system '/lib' is a symbolic link to '/usr/lib'. I was creating a PKGBUILD for a program that places a systemd service file into '/lib/systemd/...' during installation. Unfortunately, when I would like to install the created package, libalpm detects a file conflict between '/lib' (the symlink in the filesystem) and '/lib' (the directory in the package).
Yes, Arch does symlink /lib -> /usr/lib, as well as /bin and /sbin -> /usr/bin. Your PKGBUILD ought to install the service file to /usr/lib/systemd/system, which is where it will really reside.
this may or may not be an actual bug, I'm not sure if it's the intended behaviour. [...] Could someone confirm that this is indeed the intended behaviour? And if yes, why?
Pacman correctly identified /lib as a symlink and did not overwrite it with the directory from your PKGBUILD. This is the intended behavior: pacman will only install files to real destinations and does not follow symlinks, so that it can always (barring user interference) have an accurate idea of where in the filesystem the files it installed actually are.
Hi 2020. szeptember 29., kedd 0:45 keltezéssel, Ivy Foster írta:
On 28 Sep 2020, at 6:19 pm +0000, Barnabás Pőcze via pacman-dev wrote:
Hi,
Hello,
On my particular system '/lib' is a symbolic link to '/usr/lib'. I was creating a PKGBUILD for a program that places a systemd service file into '/lib/systemd/...' during installation. Unfortunately, when I would like to install the created package, libalpm detects a file conflict between '/lib' (the symlink in the filesystem) and '/lib' (the directory in the package).
Yes, Arch does symlink /lib -> /usr/lib, as well as /bin and /sbin -> /usr/bin. Your PKGBUILD ought to install the service file to /usr/lib/systemd/system, which is where it will really reside.
this may or may not be an actual bug, I'm not sure if it's the intended behaviour. [...] Could someone confirm that this is indeed the intended behaviour? And if yes, why?
Pacman correctly identified /lib as a symlink and did not overwrite it with the directory from your PKGBUILD.
This is the intended behavior: pacman will only install files to real destinations and does not follow symlinks, so that it can always (barring user interference) have an accurate idea of where in the filesystem the files it installed actually are.
I see, thanks for the explanation.
On 29 Sep 2020, at 5:59 pm +0000, Barnabás Pőcze wrote:
Hi
Hello,
2020. szeptember 29., kedd 0:45 keltezéssel, Ivy Foster írta:
On 28 Sep 2020, at 6:19 pm +0000, Barnabás Pőcze via pacman-dev wrote:
[pacman not following symlinks] may or may not be an actual bug, [...] Could someone confirm that this is indeed the intended behaviour? And if yes, why?
This is the intended behavior: pacman will only install files to real destinations and does not follow symlinks, so that it can always (barring user interference) have an accurate idea of where in the filesystem the files it installed actually are.
I see, thanks for the explanation.
No problem! It's a good question, since "everything should follow symlinks all the time" is an easy assumption to make.
participants (2)
-
Barnabás Pőcze
-
Ivy Foster