Re: [pacman-dev] [BUG] libalpm: symlink to directory causes conflict
On 28 Sep 2020, at 6:19 pm +, 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. signature.asc Description: PGP signature
Re: [pacman-dev] [PATCH] repo-add: add --include-sigs option
Hi On Thu, Sep 3, 2020 at 7:41 PM Eli Schwartz wrote: > > On 9/2/20 11:02 PM, Allan McRae wrote: > > Pacman now downloads the signature files for all packages when present in a > > repository. That makes distributing signatures within repository databases > > redundant and costly. > > > > Do not distribute the package signature files within the repo databases by > > default and add an --include-sigs to revert to the old behaviour. > > As I've mentioned on the list before, I would like an --ignore-sigs > option and continue to distribute sigs by default for pacman 6.0 I agree with Eli here. "Using embedded signatures" should stay default as long as we support clients with pacman 5.x version. Otherwise we are going to hit problems when a repo maintainer updated their system to pacman 6.x and started distributing optimized databases without signatures while some clients still expect embedded sigs. So I vote for including sigs by default in pacman 6.0 release, and then flip the default later (during 6.0.1 or 6.1 release).
[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
