PolicyKit + KDE

Matthew Woehlke mw_triad at users.sourceforge.net
Wed Sep 2 01:09:15 BST 2009

Gary Greene wrote:
> On 9/1/09 4:10 PM, "Matthew Woehlke" <mw_triad at users.sourceforge.net> wrote:
>> John Tapsell wrote:
>>>   The problem is "make install" in kdelibs/kdebase  has traditionally
>>> only installed files to your $KDEDIR directory.  However with
>>> policykit requires files to be installed elsewhere.  For example
>>> ksysguard now needs to install to:
>>> /etc/dbus-1/system.d/org.kde.ksysguard.processlisthelper.conf
>>> /usr/share/dbus-1/system-services/org.kde.ksysguard.processlisthelper.service
>>> /usr/share/PolicyKit/policy/org.kde.ksysguard.processlisthelper.policy
>>> To do so requires root privillages and modifies the main system - no
>>> longer giving us the possibility of playing with one version of kde
>>> which having another installed.
>> ...and interferes with package managers. ++!good��. I have to agree with
>> apaku on this point.
>> (�� pronounced "double-plus-ungood" :-) )
>>> I can't really see any good solution.  At minimum we could modify the
>>> build files so that it doesn't fail if you run make install as a
>>> normal user, although this means that any app requiring root rights
>>> would fail with authorization errors.  Perhaps this is sufficiently
>>> good.
>> Works for me, and is much preferable to not being able to install
>> unattended my trunk KDE builds.
> I prefer Thiago's approach (which well behaved applications like cyrus-sasl
> do) where we install in prefix as the user requested and then warn them at
> the end of the install that they've possible breakages and what they need to
> do to fix it (i.e.. Do X, Y, Z as root to make it so feature N works.)

Since that apparently covers "we could modify the build files so that it 
doesn't fail if you run make install as a normal user", I fail to see 
how that does not incorporate the best of both suggestions ;-). 
Actually, I think that's the same as above, but with the addition that 
some extra steps (as root) allows stuff to actually work.

That said, I guess I don't understand how PK works that this is even 
needed. If PK says "user may edit <certain things>", why does it matter 
if the user does that via package from packaged KDE, /bin/vi, or some 
cobbled-together C program they just compiled? Since you are talking 
about installing policy files I must guess that this is not how PK works?

Please do not quote my e-mail address unobfuscated in message bodies.
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
   -- Unknown/Anonymous

More information about the kde-core-devel mailing list