This is a bug that has been around since at least 2007. On a package
upgrade (either by -S or -U) a new directory could overwrite any file.
This is caused by the filelist difference calculation ignoring all
directories and thus no new directories were checked for conflicting
files on the filesystem.
Signed-off-by: Allan McRae <allan@archlinux.org>
Return -1 if a path is too long to resolve or we run out of memory.
Signed-off-by: Andrew Gregory <andrew.gregory.8@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
This applies to a case such as when /lib is a symlink to /usr/lib. If a
package is installed which contains /lib/libfoo.so, pacman will complain
if this package is then "fixed" to contain /usr/lib/libfoo.so. Since
these have the same effective path and it exists within the same
package, ignore the conflict.
Fixes FS#30681.
Signed-off-by: Allan McRae <allan@archlinux.org>
File paths are resolved if necessary during inter-package conflict
checks so that packages carrying the same effective file due to
directory symlinks on the filesystem are flagged as conflicting.
Signed-off-by: Allan McRae <allan@archlinux.org>
If a filename isn't resolved, the original can be used instead of strdup()ing
it.
Signed-off-by: Andrew Gregory <andrew.gregory.8@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
The _alpm_filelist_resolve function takes a filelist and creates
a list with any symlinks in directory paths resolved.
Signed-off-by: Andrew Gregory <andrew.gregory.8@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
Detect a conflict between a file/symlink in one package and a directory
in another when both are being installed at once.
A side effect is the creation of conflicts between a directory symlink
and a real directory (e.g lib -> usr/lib in pkg1 and /lib in pkg2).
Given we can not guarantee pkg1 is installed before pkg2, this is a
genuine conflict.
Signed-off-by: Allan McRae <allan@archlinux.org>
To improve conflict checking, we will need to make these functions
diverge to an extent where having two separate functions will be
preferable.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
We have a few of these and might as well gather them together. This also
cleans up the code a bit by using an enum instead of integer values, as
well as makes a "search for file in filelist" function public so
frontends can do better than straight linear search of the filelists.
Signed-off-by: Dan McGee <dan@archlinux.org>