FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 04-18-2010, 08:08 AM
Christoph Wickert
 
Default PolicyKit-authentication-agents in Fedora

Am Samstag, den 17.04.2010, 22:17 -0400 schrieb Matthias Clasen:

> So, I don't think I said 'hardcoded'. I don't care how hard or soft you
> code it. The point is that it should be the responsibility of the
> desktop environment to ensure that a polkit agent is available, not the
> responsibility of individual apps or of polkit itself.

How do you want to cover the cases where users have no desktop
environment installed then?

> For GNOME, I'll simply move the polkit-gnome-authentication-agent
> autostart file from polkit-gnome to gnome-session.

This means that other desktops can no longer make use of polkit-gnome
and user or have to provide their own desktop file. This means users can
no longer choose which agent to start. What's so bad about choice? Xfce
users might want to choose wheter to use lxpolkit or polkit-gnome.

I still don't understand what the benefit of moving the desktop file is.
90% of all users will have both packages installed, the one that
provides the agent and the one that provides the autostart file. This
means 90% will not notice a difference, but for the remaining 5%, things
will likely break.

>From a packaging POV the autostart file clearly belongs to the
application it starts just as a normal desktop file belongs to a
package.

> No. Again, the responsibility for starting the agent lies with the
> desktop, not with polkit. I frankly don't care if you 'build your own
> desktop'. In that case, your favourite polkit agent is just one more
> thing to throw in your .Xclients file.

IMHO things like openbox, fluxbox or icewm should be supported without
having to configure anything in .Xclients. They all work nicely with
autostart, IMHO there is no reason to break this.

Regards,
Christoph


--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-18-2010, 11:54 PM
Matthias Clasen
 
Default PolicyKit-authentication-agents in Fedora

On Sun, 2010-04-18 at 10:08 +0200, Christoph Wickert wrote:

> > For GNOME, I'll simply move the polkit-gnome-authentication-agent
> > autostart file from polkit-gnome to gnome-session.
>
> This means that other desktops can no longer make use of polkit-gnome
> and user or have to provide their own desktop file. This means users can
> no longer choose which agent to start. What's so bad about choice? Xfce
> users might want to choose wheter to use lxpolkit or polkit-gnome.

It doesn't mean any of that. If you want to use
polkit-gnome-authentication agent, simply start it in your session, by
whatever mechanism you prefer. The autostart file is just an
implementation detail. I might just as well make gnome-session just
launch it directly.


> >From a packaging POV the autostart file clearly belongs to the
> application it starts just as a normal desktop file belongs to a
> package.

The authentication agent is not an application. It is part of the
desktop infrastructure.



--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-21-2010, 07:55 PM
James Antill
 
Default PolicyKit-authentication-agents in Fedora

On Thu, 2010-04-08 at 18:05 +0200, Christoph Wickert wrote:
> I just imported lxpolkit into CVS, but it's not yet build because I
> don't want to break anything.
>
> We now have 3 PolicyKit-authentication-agents in Fedora:
> * polkit-gnome
> * polkit-kde
> * lxpolkit
>
> As you can see lxpolkit has the shortest name and will therefore be
> chosen by yum if anything requires PolicyKit-authentication-agent (ATM
> system-config-samba and system-config-services).

Note that another change to how we pick a provider just went in
upstream, and will likely hit rawhide tomorrow sometime:

http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=00633bee2f6b398735 1dd2fef5678f4a481f0057

...as the commit says this is "simple" so we might still not get what
people want¹ but if you do:

yum --installroot=/tmp/dep-test --releasever=12 --enablerepo=rawhide
install @base @core icewm² system-config-samba

...you now get polkit-gnome, due to the fact it only has 8 unfilled
requirements and polkit-kde has 10. Dito. notification-daemon vs.
xfce4-notifyd if you "install @base @core gdm".


¹ There are ways to game it, if needed ... but that will likely involve
pain for someone.

² Note that in rawhide gnome-session now requires polkit-gnome
explicitly, so this is mostly irrelevant for the default desktop.

--
James Antill - james@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.28
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-22-2010, 06:40 AM
Kevin Kofler
 
Default PolicyKit-authentication-agents in Fedora

James Antill wrote:
> ¹ There are ways to game it, if needed ... but that will likely involve
> pain for someone.

There are at least 2 very simple ways to game this system. Imagine we would
like to make kdebase-runtime the default notification daemon. (We actually
don't. It's just an example to prove my point.) Then consider those 2 cases:

1. The -deps metapackage. For example, if we were to set up things this way:
kdebase-runtime Provides: desktop-notification-daemon
kdebase-runtime Requires: kdebase-runtime-deps
All other Requires of kdebase-runtime are filtered.
kdebase-runtime-deps Requires "38 things".
kdebase-runtime-deps is otherwise empty.
then kdebase-runtime would win. (This scenario is more or less present
already in your commit message.)

2. The provider metapackage. This one is even simpler to put into act
because it doesn't require mucking with autoreqs. For example, consider this
scenario:
kdebase-runtime-nd Provides: desktop-notification-daemon
kdebase-runtime-nd Requires: kdebase-runtime
kdebase-runtime-nd is otherwise empty.
kdebase-runtime Requires "38 things".
then kdebase-runtime-nd would "win" and drag in kdebase-runtime.

I think yum is trying to become too smart with all those complex and fragile
heuristics. Back when it was always "shortest name", what happened, even if
sometimes suboptimal, was at least predictable!

Kevin Kofler

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

Thread Tools




All times are GMT. The time now is 02:19 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org