[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.
https://bugs.gentoo.org/show_bug.cgi?id=438790
Also see:
https://bugs.gentoo.org/show_bug.cgi?id=480898
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