[kde-linux] Polkit configuration and KDE integration

Duncan 1i5t5.duncan at cox.net
Thu Dec 26 18:37:48 UTC 2013

Stuart posted on Thu, 26 Dec 2013 20:22:27 +0400 as excerpted:

> Folks,
> OpenSuSE included the package polkit-kde-kcmmodules in version
> 12.3.  It seems this was dropped in 13.1, but the polkit and the
> polkit-kde-agent packages were kept.  Was there a reason for this as it
> seems it would be needed to manage action policies from the desktop
> configuration.  After some searching through packages on an older 12.3
> system, finally pinpointed the missing package name and was able to
> download from http://rpm.pbone.net/.
> How do I go about having this package included in the next release?

[I've no reason to x-post to the suse list, so I'm killing that one, 
following up only to the kde-linux list.]

That kcm (polkit-kde-kcmodules, just one m, as shipped by gentoo at 
least) is experimental and not intended for ordinary user use.  In fact, 
it's known to trigger various hard to trace polkit bugs.  As such, its 
upstream kde devs do not recommend installing it at all.

The problem is that it directly edits system config files that are 
supposed to remain as-shipped by the distro, instead of making changes to 
the local specific system files, and/or user specific files in /home.  
Distro updates may then overwrite only part of the changed policy, 
creating a Frankenstein of a configuration that matches neither the distro 
shipped policy nor the local admin's original changes, creating all sorts 
of problems due to the now mismatched and invalid config, and thoroughly 
confusing both the user who used the tool to change settings, and the 
distro maintainers trying to trace the bugs filed as a result, because 
the behavior matches exactly nothing anybody set as it's now an invalid 
and insane hodgepodge.

Meanwhile, kde frameworks 5 will make the situation much simpler to deal 
with, as it'll honor the freedesktop.org XDG_CONFIG_DIRS and 
XDG_CONFIG_HOME environmental vars, making patching to do the right thing 
either trivial or entirely unnecessary.  Since frameworks 5 is what 
upstream kde is focused on now, they aren't particularly interested in 
fixing this package for kde4, when it was only experimental code not 
intended for default installation in any case.

I happen to know about the situation as I have gentoo/kde's git-based 
overlay installed and religiously check the git logs every time I update 
for changes I may need to know about.  Thus I read the git log and 
because it looked interesting, followed thru to the gentoo bug where all 
this was discussed for gentoo.


Also see:


The package does remain available in gentoo, but it's hard-masked, so 
anyone wishing to install it must deliberately unmask it first, and as 
usual when running hard-masked packages, "if it breaks, you get to keep 
the pieces!"  

So it's unlikely you'll get the package installed by default, and on 
distros without a masking mechanism similar to gentoo's it likely won't 
be shipped at all, for kde4 anyway.  It may appear in hopefully more 
mature form for kde frameworks 5, or not; it's really a bit early to say 
at this point.

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

More information about the kde-linux mailing list