Re: PolicyKit authentication agent changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Samstag, den 26.02.2011, 11:58 +0100 schrieb Kevin Kofler:
> Christoph Wickert wrote:
> 
> > Am Mittwoch, den 23.02.2011, 20:08 -0500 schrieb Matthias Clasen:
> >> Thats between you and the window managers... but
> >> as far as gnome is concerned, we don't want to depend on anything
> >> virtual, but control which agent is running.
> > 
> > I can understand this very well, but I never said the DE should depend
> > on the virtual provides, the applications should. A DE should depend on
> > the agent of the desktop, the apps should depend on a generic agent and
> > use the virtual provides.
> 
> Well, having the apps depend on the virtual Provides is only of limited use 
> because what yum picks if you're lacking an agent is not necessary the 
> correct agent for your desktop.

yum should pick the correct agent in most cases because it has a
provider to only install as little packages as necessary. If you have
GTK+ apps installed it wont install polkit-kde because of the whole QT /
KDE dependencies.

> The app cannot really know what agent is the 
> correct one, so there's no good way to put the dependency in the app. (We 
> can only have the app depend on "any PolicyKit authentication agent", which 
> is what the virtual Provides does, but this still doesn't ensure that the 
> correct one for your desktop is present.)
> 
> Therefore, the dependency really needs to be carried by the desktop 
> environment,

I fully agree to what you wrote and I never said something different. A
desktop can depend on an agent - given that if it includes one.

>  at which point there's no point in having the apps Require 
> anything at all. 

Please try to look beyond the rim of your KDE teacup for a moment. What
about the DEs / WMs that do not provide a polkit agent? Shouldn't we
make things like virt-manager just work in *every* environment?

> IMHO, PolicyKit authentication should just be considered a 
> basic desktop service which is present in ANY GUI desktop, it's up to the 
> desktop environment to Require the proper agent (and up to there, I 
> definitely agree with Matthias). In fact, kdebase-workspace already 
> Requires: polkit-kde.

Again you are arguing from the POV of a full featured DE. Take Xfce for
example: It is a very complete environment but still lacks a polkit
agent.

We could even go one step further and question your approach: I need to
use some KDE applications and due to the monolithic packaging I also
need to install kdebase-workspace. But I never start KDE, so why am I
forced to install a second polkit agent then? I have to admit that I
don't know the answer to this question and requiring polkit-kde looks
like the best solution because my situation is a corner case.

> Once we're there, Matthias is saying that we can just as well have the 
> desktop also START the authentication agent. I'm not entirely sure that this 
> is the best approach, but at that point, this isn't really THAT important. 

It is because it breaks other desktops.

> You have to put in a Requires for the authentication agent anyway, 

s/the/an. 'The' agent can only be used if there is one.

> so at that point you can just as well drop in an autostart file, too. 

Sure we can, but where is the advantage? If the package is required
anyway we could just leave the file where it is and belongs - with the
benefit that it can be used in other desktops, too.

> (And in 
> fact, don't some of the desktops/WMs you have in mind require their own non-
> XDG autostart setup anyway?)

Yes, this is something we should try to cover too, but for a start I
suggest to solve the situation for the XDG compliant ones.

> > Imagine you install gnome-packagekit in Xfce: It will pull in say
> > polkit-gnome but still not work.
> 
> That's exactly why it's not the app's job to pull in an authentication 
> agent. 

Which basically means that you don't care about all DEs / WMs in Fedora
being (more or less) broken because we cannot run many of our
system-config-* tools there.

> (Any application (as opposed to desktop environment / workspace) 
> package with an explicit Requires on a specific agent is broken and needs to 
> be fixed.)

Yes, an application with an explicit requires for a *specific* agent is
broken (and I'm filing bugs like #668156 in this case) but that doesn't
mean that it should not depend on a *generic* agent. If the app cannot
run without the agent, it needs this requirement.

> > Summing it all up: I still don't see the benefit of the new packaging.
> > polkit-gnome-authentication-agent-1 doesn't start on any 'random'
> > desktop. Indeed this is a step in the right direction and I appreciate
> > it because I'm on the receiving side of bugs [1].
> > 
> > But wether or not polkit-gnome-authentication-agent-1 starts on any
> > 'random' desktop has nothing to do with your new packaging but with the
> > fact that you have switched from "NotShoIn" to "OnlyShowIn". The exactly
> > same effect could be achieved without changing the packaging, so there
> > is no benefit, but on the other hand it breaks many DEs / WMs that you
> > might not care about.
> 
> The OnlyShowIn change would be breaking "random other WMs" anyway, if they 
> expected polkit-gnome to run. And if not, why do you care where the 
> autostart file sits? If it's OnlyShowIn=GNOME;, it'll have no effect for you 
> anyway.

Please take the time to read my initial proposal or my previous mail. I
said that all agents *but* *one* should have OnlyShowIn. The remaining
one gets "NotShowIn" to not conflict with the others. I suggested this
one to be lxpolkit because it has only a few deps and will be pulled in
by yum if all other providers match of because it's name.

If anybody has a better idea, I am keen to hear it but so far nothing
sounded convincing to me.

Regards,
Christoph


-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux