CMake kauth_install_* with system kauth and user CMAKE_INSTALL_PREFIX

[Milian Wolff]

On Montag, 19. Oktober 2020 13:33:38 CEST Christophe Giboudeaux wrote:
> On lundi 19 octobre 2020 12:30:59 CEST Milian Wolff wrote:
> > 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.poli
> > > >   cy
> > > >   "
> > > >   
> > > >   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/polkitbac
> > > ke
> > > nd /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?
> 
> Yes. Polkit is a security tool, it doesn't allow reading files in random
> locations.

Sure, I understand this reasoning. But I don't get how one is supposed to use 
it then as a developer - I don't want to overwrite the polkit files that got 
installed through my package manager e.g.

> > 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...
> 
> kauth can be configured with -DKAUTH_BACKEND_NAME=FAKE

I don't want to build kauth, I want to build ktexteditor, so this is where I'd 
like to disable the polkit installation. But ideally that should be generic 
and applicable to all users of KAuth - I'll prepare a patch for KAuth to get a 
cmake cache var added that can be used for this purpose then.

Cheers

-- 
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/c503fe7b/attachment.sig>