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-08-2010, 06:13 PM
Christoph Wickert
 
Default PolicyKit-authentication-agents in Fedora

Am Donnerstag, den 08.04.2010, 13:37 -0400 schrieb Bill Nottingham:
> Christoph Wickert (christoph.wickert@googlemail.com) said:
> > Suggestion:
> > GNOME and KDE use their agents, everything else, for example window
> > managers like icewm or openbox, gets lxpolkit.
>
> I'd honestly prefer they use the GNOME one (maintained closer to the
> source, etc.) unless there are speicfic problems with it.

So far there are no problems, but when GConf2 or others get pulled in,
we might get into trouble. People are not using a lightweight WM in
order to install half of GNOME.

> > Rationale:
> > 2. lxpolkit is the smallest package.
>
> 20k of code vs 70k of code? Is that really something worth caring about?
> (Yes, the GNOME PK agent ends up being about 300k installed, but given
> that it's translated into 30+ languages as opposed to lxpolkit's < 10...)

lxpolkit is very young, it was announced a week ago and the number of
translations is continuously rising.
Nevertheless I agree that polkit-gnome offers the most value: It has
more translations and it has the option to cache the password with a
nice tray icon.

> > 3. lxpolkit will be pulled in anyway due to the shortest name.
>
> That's not a useful decision rationale.

I never said it is a useful decision rationale, it's something we cannot
avoid. I agree it's not useful, but please address your complainants to
the yum developers.

Let me repeat what I already said in my previous mail: I don't mind
polkit-gnome as default agent, but
* I'm afraid that yum will choose lxpolkit
* I'm afraid polkit-gnome will have more deps in the future
* we cannot yet use OnlyShowIn=LXDE

> Bill

Regards,
Christoph

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-08-2010, 06:19 PM
Seth Vidal
 
Default PolicyKit-authentication-agents in Fedora

On Thu, 8 Apr 2010, Christoph Wickert wrote:

>>> 3. lxpolkit will be pulled in anyway due to the shortest name.
>>
>> That's not a useful decision rationale.
>
> I never said it is a useful decision rationale, it's something we cannot
> avoid. I agree it's not useful, but please address your complainants to
> the yum developers.
>
> Let me repeat what I already said in my previous mail: I don't mind
> polkit-gnome as default agent, but
> * I'm afraid that yum will choose lxpolkit
> * I'm afraid polkit-gnome will have more deps in the future
> * we cannot yet use OnlyShowIn=LXDE


I'm all ears - tell me another way of how we should know that of 3 items
one should be chosen over the others?

We've got lots of criteria we use to score up/down pkgs in
compare_providers in yum. It's not just length of pkg name.

But at the end of the day, it is possible that length of pkg name could be
the deciding variable.

Would you rather we pull one at random?

-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-08-2010, 06:22 PM
Matthias Clasen
 
Default PolicyKit-authentication-agents in Fedora

On Thu, 2010-04-08 at 14:19 -0400, Seth Vidal wrote:
>
> On Thu, 8 Apr 2010, Christoph Wickert wrote:
>
> >>> 3. lxpolkit will be pulled in anyway due to the shortest name.
> >>
> >> That's not a useful decision rationale.
> >
> > I never said it is a useful decision rationale, it's something we cannot
> > avoid. I agree it's not useful, but please address your complainants to
> > the yum developers.
> >
> > Let me repeat what I already said in my previous mail: I don't mind
> > polkit-gnome as default agent, but
> > * I'm afraid that yum will choose lxpolkit
> > * I'm afraid polkit-gnome will have more deps in the future
> > * we cannot yet use OnlyShowIn=LXDE
>
>
> I'm all ears - tell me another way of how we should know that of 3 items
> one should be chosen over the others?
>

One interesting criterium might be 'pulls in the least uninstalled
deps'. That would probably handle a lot of cases like the one at hand
nicely.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-08-2010, 06:37 PM
Christoph Wickert
 
Default PolicyKit-authentication-agents in Fedora

Am Donnerstag, den 08.04.2010, 14:22 -0400 schrieb Matthias Clasen:
> On Thu, 2010-04-08 at 14:19 -0400, Seth Vidal wrote:
> >
> > On Thu, 8 Apr 2010, Christoph Wickert wrote:
> >
> > >>> 3. lxpolkit will be pulled in anyway due to the shortest name.
> > >>
> > >> That's not a useful decision rationale.
> > >
> > > I never said it is a useful decision rationale, it's something we cannot
> > > avoid. I agree it's not useful, but please address your complainants to
> > > the yum developers.
> > >
> > > Let me repeat what I already said in my previous mail: I don't mind
> > > polkit-gnome as default agent, but
> > > * I'm afraid that yum will choose lxpolkit
> > > * I'm afraid polkit-gnome will have more deps in the future
> > > * we cannot yet use OnlyShowIn=LXDE
> >
> >
> > I'm all ears - tell me another way of how we should know that of 3 items
> > one should be chosen over the others?
> >
>
> One interesting criterium might be 'pulls in the least uninstalled
> deps'. That would probably handle a lot of cases like the one at hand
> nicely.

+1, that's what I was just about to suggest.

When I look into the critical path list, I see that there are also Xfce
packages in there. This is due to xfce4-notifyd and notification-daemon
both providing "desktop-notification-daemon".

At the point where xfce4-notifd gets pulled in, the notification-daemon
and it's deps were already processed, so I don't understand why yum adds
another 5 packages added (xfce4-notifyd, libsexy, xfconf, libxfce4util
and libxfcegui4).

Regards,
Christoph

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-08-2010, 09:02 PM
Adam Williamson
 
Default PolicyKit-authentication-agents in Fedora

On Thu, 2010-04-08 at 20:13 +0200, Christoph Wickert wrote:
> Am Donnerstag, den 08.04.2010, 13:37 -0400 schrieb Bill Nottingham:
> > Christoph Wickert (christoph.wickert@googlemail.com) said:
> > > Suggestion:
> > > GNOME and KDE use their agents, everything else, for example window
> > > managers like icewm or openbox, gets lxpolkit.
> >
> > I'd honestly prefer they use the GNOME one (maintained closer to the
> > source, etc.) unless there are speicfic problems with it.
>
> So far there are no problems, but when GConf2 or others get pulled in,
> we might get into trouble. People are not using a lightweight WM in
> order to install half of GNOME.

Is there any particular reason polkit-gnome-authentication-agent
couldn't be polkit-gtk-authentication-agent instead, and explicitly be
designed to be GNOME dependency-free and hence suitable for other
GTK-ish desktops? It seems a bit odd to mushroom off three different
implementations of what's really a fairly simple widget...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-08-2010, 09:56 PM
Matthias Clasen
 
Default PolicyKit-authentication-agents in Fedora

On Thu, 2010-04-08 at 14:02 -0700, Adam Williamson wrote:
> On Thu, 2010-04-08 at 20:13 +0200, Christoph Wickert wrote:
> > Am Donnerstag, den 08.04.2010, 13:37 -0400 schrieb Bill Nottingham:
> > > Christoph Wickert (christoph.wickert@googlemail.com) said:
> > > > Suggestion:
> > > > GNOME and KDE use their agents, everything else, for example window
> > > > managers like icewm or openbox, gets lxpolkit.
> > >
> > > I'd honestly prefer they use the GNOME one (maintained closer to the
> > > source, etc.) unless there are speicfic problems with it.
> >
> > So far there are no problems, but when GConf2 or others get pulled in,
> > we might get into trouble. People are not using a lightweight WM in
> > order to install half of GNOME.
>
> Is there any particular reason polkit-gnome-authentication-agent
> couldn't be polkit-gtk-authentication-agent instead, and explicitly be
> designed to be GNOME dependency-free and hence suitable for other
> GTK-ish desktops? It seems a bit odd to mushroom off three different
> implementations of what's really a fairly simple widget...

First of all, the fear of GConf has really grown to quite irrational
levels. Just look at
http://wiki.lxde.org/en/Google_Summer_of_Code_2010#Fork_GVFS_to_provide_a_ more_lightweight.2C_stripped_down_version_without_ Gnome_dependency


Anyway, studying rpm -q --requires polkit-gnome, I have a really hard
time coming up with anything that could be objectionable, bloated or
unnecessary:

libatk-1.0.so.0()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libcairo.so.2()(64bit)
libfontconfig.so.1()(64bit)
libfreetype.so.6()(64bit)
libgdk-x11-2.0.so.0()(64bit)
libgdk_pixbuf-2.0.so.0()(64bit)
libgio-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgmodule-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libgtk-x11-2.0.so.0()(64bit)
libpango-1.0.so.0()(64bit)
libpangocairo-1.0.so.0()(64bit)
libpangoft2-1.0.so.0()(64bit)
libpolkit-agent-1.so.0()(64bit)
libpolkit-gobject-1.so.0()(64bit)
libpolkit-gtk-1.so.0()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
librt.so.1()(64bit)
polkit >= 0.95
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1


Just what do you want to strip out here ?


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

Thread Tools




All times are GMT. The time now is 08:45 AM.

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