"kde5" or "kf5" ?

[David Faure]

On Saturday 16 February 2013 17:23:46 Sune Vuorela wrote:
> On 2013-02-16, Alexander Neundorf <neundorf at kde.org> wrote:
> > _set_fancy(LIBEXEC_INSTALL_DIR  "${LIB_INSTALL_DIR}/kde5/libexec")
> 
> I still don't see a reason for a *shared* libexec directory. libexec is
> implementation details of specific libraries, just like one shouldn't
> mess around with each others private's in the code, one also shouldn't
> mess around with other's libexec bits.
> 
> so libfoo's libexec should be lib_install_dir/foo/libexec

I like this solution. It answers my long-lasting question about why there 
isn't a standardized libexec path (so that QStandardPaths::findExecutable) can 
look into it. If there isn't a standard path, then we might as well split it 
per lib indeed.

Any volunteer for porting the current uses of LIBEXEC_INSTALL_DIR everywhere 
in kdelibs-frameworks (both in cmakelists.txt and in code)?

Then we can get rid of the above variable.

> > _set_fancy(XDG_APPS_INSTALL_DIR
> > "${SHARE_INSTALL_PREFIX}/applications/kde5" )
> I'm also a bit unsure about this one. Sure it is nice to avoid path
> conflicts with other applications hogging the same desktop file names,
> but from the different end of things: if things does hog the same
> desktop file name, the content of the file is probably going to be so
> similar that everyone wants to know about it and ensure that the content
> is different enough.

Yeah, and this has always created compatibility problems IMHO (with other DEs, 
due to kate.desktop vs kde4-kate.desktop vs kde4/kate.desktop).

Let's remove the /kde5 then.

This leaves the "kde5" in front of "services" and "servicetypes". A subdir is 
necessary there, to separate kde4-based from KF5-based plugins.
But IIRC Kévin convinced me some time ago to say kf5 instead of kde5.
My thinking was "any app will want to install stuff there, so it's not kf5-
specific", but this is about adding files for use by the KF5 kservices 
framework, so why not.

Executive summary: it's "kf5" everywhere.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by BlueSystems and KDAB to work on KDE Frameworks