[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 229735] Installing KDE in "/usr/KDE-4.4 breaks Authorization.
From:       Dario Freddi <drf () kde ! org>
Date:       2010-03-09 18:39:00
Message-ID: 20100309183900.8D52536B84 () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=229735





--- Comment #9 from Dario Freddi <drf kde org>  2010-03-09 19:38:53 ---
(In reply to comment #8)
> > (In reply to comment #6)
> 
> OK. I have kde-4.4.0 installed in /opt/kde-4.4. The result of your advice (
> thank you very much for your hints ) was not successfull:
> 
> 1.) There does not exist an /opt/kde-4-4/share/polkit directory. However, as we
> instaled PolicyKit-0.9 and polkit-0.96 in /usr, it exists an
> /usr/share/polkit-1/actions/ directory. Following your hint, we created an
> /usr/polkit/actions directory, and cp the contents of the corresponding
> /usr/share/polkit-1/actions/ to it. Just to remind: we are alredy talking about
> polkit, policykit and polkit-1 and guessing directories.

Sorry, my bad. it was
sudo cp $KDEPREFIX/share/polkit-1/actions/* /usr/polkit-1/actions

I wrote this in a hurry. However, this is valid if you are using polkit-1 as
KAuth's backend. If you did not specify anything explicitely and you have both
polkit and PolicyKit installed, it's quite likely PolicyKit got chosen, since
it's the default of KDE 4.4. However cmake's output in kdelibs should tell you
what's being built. If you have PolicyKit as a backend, the command is

sudo cp $KDEPREFIX/share/PolicyKit/policy/* /usr/PolicyKit/policy

> The result of all, after rebooting, trying to modify the time:
> "You are not allowed to save the configuration"

Expected, as the action dir was wrong. Please retry with the hints from above.

> 
> > And you know you can't even install the plasma python engine in a different
> > prefix as well, do you? I think you can see the point now. And copying some
> > files is not rocket science.
> 
> Let me please make some additional comments:
> 
> 1. We should slow down the discussion. We all are only trying to get KDE-4.4
> running smootly, helping in the way each one of us can. I e.g. as experienced
> user.

I know, and I can assure you I am not that rude usually. But I don't like
getting attacked for no reasons, as you can read above. If a decent attitude
was shown in the first place I would have reacted differently. It was not so
hard after all.

You guys should realize that we don't write a poem in answer to a bug report
because we are repeating the same thing over and over - and in our free time. I
felt really insulted by such an attitude, like I think everyone would have.

> 
> 2. If very important programs are running under kde-3.5 and suddenly not more
> under kde-4.4 due to safety issues, and I am not able and allowed to make the
> necessary changes ( time ), then kde-4.4 has a problem.

Yes, but still (as you can see) you can fix that by moving some files. Probably
this should be added somewhere (I repeated this hint a gazillion times to a lot
of people but never got written anywhere), and it makes sense, as if you are
compiling software from source dealing with this kind of stuff (root privileges
and stuff), moving some files is a decent compromise. Otherwise you might end
up (see the conclusion of the mail) installing permissions allowing you to
perform actions as root as a normal user - not really making sense, isn't it?

> 
> 3. Part of the problem is the inconsistency of sources. Sometimes trunk,
> sometimes kdesupport, sometimes git. And the versions are not compatible.

Uhm, I did not get this actually. What are you talking about in specific?

> 
> 4. There are not explanations about PolicyKit, polkit, polkit-qt, polkit-qt-1.
> Are they all compatible ? or are they excluding each other perhaps ? But these
> programs seem to be ruling the authorization issues !

Please read my blogpost about that, which is quite explainatory:
http://drfav.wordpress.com/2009/12/22/polkit-and-kde-lets-make-the-point-of-the-situation/
Unfortunately this has been due to reasons external to KDE: however KAuth
(hence KDE apps) supports both of them, but still ONLY ONE will be used, and
this is decided at compile time in KDELIBS (and you can force it, please read
documentation in kdelibs/kdecore/auth/ConfigureChecks.cmake or simply have a
look at your CMake cache).

This is what we did to shield us from the polkit disaster, and we managed it
quite well. So again, after all the work (a lot, I might add) that came into
making both dependencies pluggable and optional, hearing that apparently "I
don't care" is extremely frustrating, because you really don't want to know
what would have happened if KAuth did not exist and polkit/PolicyKit was a hard
dependency. We in KDE are in an extremely privileged situation regarding this
matter now, and this has been achieved using KDE technologies only. So we _do_
care about our users here.

> 
> 5.) last but not least, also you could observe, that copying files may advance
> to a rocket science.

Well, I assume that if you created such a situation, you are able to compile
from source to a different prefix than default, hence you are surely more than
able to move some files around :)

> 
> I don't believe, that the intention of the KDE-developers is to develop only
> for distributor companies. There are thousands of self building users. I am
> one, pretty well experienced. The system, at this moment, needs more attention
> in this sense.

I can't agree with you here - as you have seen, I can do nothing more than
adding this part myself to the "compilation from source" tutorial, and I hope
you realize this. There is no way of fixing this situation in DBus and
polkit/PolicyKit, and I doubt the situation will change in the future. That's
the point I'm trying to state.

This -has had attention-, and a lot: there has been a wide discussion over
this. A first idea, that was scratched, was to force the prefix to /usr, but we
preferred to stay this way to allow people to build wherever they wanted, and
just spit out a phat warning at cmake time. So we _do_ care about this.

Still, there are some good reasons for polkit and dbus to have the
configuration handled this way - even the "solution" proposed by James won't
really work, and still would require you to issue "make install" as superuser,
which you surely don't want if you're installing KDE to your home directory,
for example.

So the best solution to the problem is simply installing wherever, and moving
those files.

BTW, the proof to all of this is that I compile KDE to ~/kde, just like you.
And I have authorizations & stuff working, as you might imagine, just by moving
files installed in those three directories. I agree the process could be
documented better and I would be happy if you could point me to the relevant
documentation so that I can update it.

You know, if the second message had been "Ok, can you please tell me if there
is a fix for this?", probably we wouldn't be talking and wasting each other's
time right now. But that's how it goes.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]