CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

Milian Wolff mail at milianw.de
Mon Oct 19 11:30:59 BST 2020


On Montag, 19. Oktober 2020 11:27:29 CEST Harald Sitter wrote:
> Yo
> 
> On 18.10.20 10:11, Milian Wolff wrote:
> > Hey all,
> > 
> > since some time now I'm only compiling parts of KF5 selectively into a
> > custom prefix. Most notably, I'm only interested in ktexteditor and
> > syntax- highlighting, and would like to obtain all other frameworks
> > through my distribution packages.
> > 
> > Sadly, this doesn't work as easily, as ktexteditor is trying to do this:
> > 
> > ```
> > install(TARGETS kauth_ktexteditor_helper DESTINATION $
> > {KAUTH_HELPER_INSTALL_DIR} )
> > kauth_install_helper_files(kauth_ktexteditor_helper
> > org.kde.ktexteditor.katetextbuffer root)
> > kauth_install_actions(org.kde.ktexteditor.katetextbuffer buffer/
> > org.kde.ktexteditor.katetextbuffer.actions)
> > ```
> > 
> > Because my KAuth is a system-provided installation, and KTextEditor should
> > be installed into a user-writable prefix, I get this error on `ninja
> > install`:
> > 
> > ```
> > 
> > CMake Error at src/cmake_install.cmake:143 (file):
> >   file INSTALL cannot copy file
> >   "/home/milian/projects/kf5/build/frameworks/ktexteditor/src/
> > 
> > org.kde.ktexteditor.katetextbuffer.policy"
> > 
> >   to
> >   "/usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.policy"
> >   :
> >   Permission denied.
> > 
> > Call Stack (most recent call first):
> >   cmake_install.cmake:77 (include)
> > 
> > ```
> > 
> > I can workaround this by either commenting out the kauth install bits in
> > ktexteditor or by installing kauth seperately too. But both are in my
> > opinion not ideal.
> > 
> > I don't think it's currently possible to overwrite the KAuth install
> > directory at cmake configure time. I would like to change that, unless
> > there is something I'm missing which would prevent this? I am hoping that
> > any folder works as long as it's listed in the `XDG_DATA_DIRS` env var -
> > can someone confirm this?
> 
> Alas, the path is hardcoded at buildtime from what I see:
> https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitbackend
> /polkitbackendinteractiveauthority.c#L302
> 
> Relevant: https://bugs.kde.org/show_bug.cgi?id=425272

So the path that needs to be used is actually the polkit path? Meaning the 
question where KAuth is being installed to doesn't really matter? That would 
imply that KAuth is broken anyways when it's not installed to the same prefix 
that polkit is being installed to, no?

If so, then it's just one more reason to be able to skip kauth policy 
installation, as they won't be picked up anyways...

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20201019/935f1a40/attachment.sig>


More information about the kde-core-devel mailing list