Qt-5 webkit wont install as it is already in filesystem

qt5-webkit: /usr/lib64 exists in filesystem (owned by filesystem)
qt5-webkit: /usr/lib64/cmake/Qt5WebKit/Qt5WebKitConfig.cmake exists in file
system
qt5-webkit: /usr/lib64/cmake/Qt5WebKit/Qt5WebKitConfigVersion.cmake exists
in filesystem
qt5-webkit: /usr/lib64/cmake/Qt5WebKit/WebKitTargets-noconfig.cmake exists
in filesystem
qt5-webkit: /usr/lib64/cmake/Qt5WebKit/WebKitTargets.cmake exists in filesy
stem
qt5-webkit: /usr/lib64/cmake/Qt5WebKitWidgets/Qt5WebKitWidgetsConfig.cmake
exists in filesystem
qt5-webkit: /usr/lib64/cmake/Qt5WebKitWidgets/Qt5WebKitWidgetsConfigVersion
.cmake exists in filesystem
qt5-webkit: /usr/lib64/cmake/Qt5WebKitWidgets/Qt5WebKitWidgetsTargets-nocon
fig.cmake exists in filesystem
qt5-webkit: /usr/lib64/cmake/Qt5WebKitWidgets/Qt5WebKitWidgetsTargets.cmake
exists in filesystem

See that it comments that /user/lib64 is already in file system so I think it is not just a mater of deleting the older version of the package. Should I wait for an update on the pkgbuild?

Probably the safest. Although I’m no expert, so might be wrong, but that’s probably the safest.

If you’re feeling brave — use at your own risk! — you could go… :point_down:

yay -Syu qt5-webkit --overwrite="/usr/*"
2 Likes

Nothing should be installed directly in /usr/lib64/, it’s a symlink to /usr/lib/. Maybe comment on the AUR page to let the maintainer know.

It is a likely result of a previous run of a local compile without using the package manager to install the files.

Such previous install will throw the messages you get - then - as @Yochanan points out /usr/lib64 - that is not correct.

I just did a build of qt5-webkit - using the PKGBUILD from AUR - with no errors and a clean install.

git clone https://aur.archlinux.org/qt5-webkit
cd qt5-webkit
makepkg -iscC

As I have timeshift I just snapshoted the system and did it. Seem to be alright :slight_smile:

Why do you think that symlink exists? :wink:

The source code is quite generic — it includes routines for building on iOS — and therefore it is safer for the code to assume /usr/lib64 than to assume /usr/lib, because the latter could cause problems on 64-bit systems where /usr/lib is still used to house 32-bit libraries. :wink:

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.