GNOME Bugzilla – Bug 645402
bring back the autostart file
Last modified: 2011-03-28 14:47:57 UTC
right now the gnome fallback doesn't get any authorization because the autostart file was dropped and all the others DEs are broken because of that too. pro arguments to add it back: *is a simple solution that makes gnome fallback work again *the other DEs don't have to ship their custom autostart Tested with: AutostartCondition=GNOME3 if-session gnome-fallback
(In reply to comment #0) > right now the gnome fallback doesn't get any authorization because the > autostart file was dropped and all the others DEs are broken because of that > too. > > pro arguments to add it back: > > *is a simple solution that makes gnome fallback work again > *the other DEs don't have to ship their custom autostart Sorry, but this is just not a good reason to bring it back. - By the same token, should we also start nautilus (in case they don't have a file manager) or nm-applet? Or what about gnome-keyring in case they don't have a ssh-agent? - And what happens if a DE wants to provide their own authentication agent? We then add exceptions to the autostart file? How does that work with downstreams that has version skew between the DEs in their releases? (e.g. recent gnome, older non-gnome DE) We ran into a ton of the latter problems in Fedora and that's ultimately why it was determined that this is a bad idea. It's a much better architecture if the non-GNOME DE in question ships its own autostart file (for /usr/libexec/polkit-gnome-authentication-agent-1 or their own agent, I don't care).
Reasons I think it should be in polkit-gnome and not gnome-session: - polkit-gnome is no more special than g-s-d, notification-daemon or any other program. All of those ship a .desktop file. - other desktops are using polkit-gnome, and it's less work to only have one .desktop file than to ask everyone to ship it. Note that it's the reason why Debian, Gentoo and openSUSE all choose the option to ship the .desktop file in polkit-gnome. - I don't think adding a desktop to OnlyShowIn once every 6 months is a big deal, so to me it feels like this is not a good reason to not have the .desktop file in polkit-gnome. I'm even willing to maintain the .desktop file in polkit-gnome if that helps. On top of that, it makes also more sense to ship it in polkit-gnome because this way, if anything changes in polkit-gnome wrt how it's started, then the change won't involve remembering to change autostart files in various places; and it also makes more sense because it helps translators keep all related strings together.
@David lets stop thinking about other DEs. Gnome 3.0 fallback mode is still broken. Provide a fix until 3.0 is released
(In reply to comment #2) > Reasons I think it should be in polkit-gnome and not gnome-session: > > - polkit-gnome is no more special than g-s-d, notification-daemon or any other > program. All of those ship a .desktop file. Uhm. If notification-daemon ships an autostart file then it's surely a broken because then I can't have notification-daemon installed and run a DE that wants to implement the same functionality (unless notification-daemon already knows about this). Btw, I'm honestly surprised you think this is a sane approach... it's totally conflating mechanism (providing the program showing notifications) and policy (should I start the problem showing notifications). > - other desktops are using polkit-gnome, and it's less work to only have one > .desktop file than to ask everyone to ship it. Note that it's the reason why > Debian, Gentoo and openSUSE all choose the option to ship the .desktop file in > polkit-gnome. That's their problem then.... good luck maintaining that mess in those distros. I'm just glad I don't have to. > - I don't think adding a desktop to OnlyShowIn once every 6 months is a big > deal, so to me it feels like this is not a good reason to not have the .desktop > file in polkit-gnome. I'm even willing to maintain the .desktop file in > polkit-gnome if that helps. You don't think it's a big deal? Dude, it's still extra work that is _not needed_ if a better solution is used. And, no, I'm not adding it back even with you offering to help - I really think you should spend your time on better things :-) > On top of that, it makes also more sense to ship it in polkit-gnome because > this way, if anything changes in polkit-gnome wrt how it's started, then the > change won't involve remembering to change autostart files in various places; > and it also makes more sense because it helps translators keep all related > strings together. FWIW, I don't think strings like [X] Start daemon XYZ to implementing nerdy OS interface org.foobar.Abc should ever appear in the UI _anyway_ but maybe that's just me.... and even if we do show these strings, it's probably better to have them all in the same place _anyway_ so you get the same style. But meh.
(In reply to comment #3) > @David lets stop thinking about other DEs. > > Gnome 3.0 fallback mode is still broken. Provide a fix until 3.0 is released Uh, what kind of statement is that? Please be more specific - things work just fine here on my system. Suggest that you complain to your distro vendor first.
(In reply to comment #5) > (In reply to comment #3) > > @David lets stop thinking about other DEs. > > > > Gnome 3.0 fallback mode is still broken. Provide a fix until 3.0 is released > > Uh, what kind of statement is that? Please be more specific - things work just > fine here on my system. Suggest that you complain to your distro vendor first. without polkit-gnome-authentication-agent-1 you won't be able to mount partion, change clock, install packages, change cpu frequency, shutdown, because there is nobody starting that tool.
(In reply to comment #4) > (In reply to comment #2) > > Reasons I think it should be in polkit-gnome and not gnome-session: > > > > - polkit-gnome is no more special than g-s-d, notification-daemon or any other > > program. All of those ship a .desktop file. > > Uhm. If notification-daemon ships an autostart file then it's surely a broken > because then I can't have notification-daemon installed and run a DE that wants > to implement the same functionality (unless notification-daemon already knows > about this). The way notification-daemon implemented this is by shipping a .desktop file in /usr/share/applications (so, not for autostart), with no mention of OnlyShowIn/NotShowIn. And gnome-session references this .desktop file. Not forcing gnome-session to know what is the content of the .desktop file is my main worry. I'm fine saying "gnome-session should start these 5 components". It's avoiding the issues you're raising -- in a way that I think is suboptimal because it won't work for other desktops, but that's my opinion ;-)
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > @David lets stop thinking about other DEs. > > > > > > Gnome 3.0 fallback mode is still broken. Provide a fix until 3.0 is released > > > > Uh, what kind of statement is that? Please be more specific - things work just > > fine here on my system. Suggest that you complain to your distro vendor first. > > without polkit-gnome-authentication-agent-1 you won't be able to mount partion, > change clock, install packages, change cpu frequency, shutdown, because there > is nobody starting that tool. That's not a polkit-gnome problem - it's a gnome-session problem. It's not my problem that the gnome-session maintainers won't ship the autostart file - the change was clearly announced here http://lists.freedesktop.org/archives/polkit-devel/2011-February/000343.html a long time ago. And you do not have to explain the implications of this to me - I wrote both PolicyKit and many of the mechanisms using it :-)
(In reply to comment #7) > (In reply to comment #4) > > (In reply to comment #2) > > > Reasons I think it should be in polkit-gnome and not gnome-session: > > > > > > - polkit-gnome is no more special than g-s-d, notification-daemon or any other > > > program. All of those ship a .desktop file. > > > > Uhm. If notification-daemon ships an autostart file then it's surely a broken > > because then I can't have notification-daemon installed and run a DE that wants > > to implement the same functionality (unless notification-daemon already knows > > about this). > > The way notification-daemon implemented this is by shipping a .desktop file in > /usr/share/applications (so, not for autostart), with no mention of > OnlyShowIn/NotShowIn. And gnome-session references this .desktop file. > > Not forcing gnome-session to know what is the content of the .desktop file is > my main worry. I'm fine saying "gnome-session should start these 5 components". > > It's avoiding the issues you're raising -- in a way that I think is suboptimal > because it won't work for other desktops, but that's my opinion ;-) Please explain exactly how this works with GNOME Shell where we don't want notification-daemon started (but we do want it for fallback mode).... (there used to be (and probably still is) a lot of racy code for ensuring that the shell could own the name org.freedesktop.Notications ...)
(In reply to comment #9) > Please explain exactly how this works with GNOME Shell where we don't want > notification-daemon started (but we do want it for fallback mode).... It just won't get started in the GNOME Shell session. Compare http://git.gnome.org/browse/gnome-session/tree/data/gnome.session.desktop.in.in (gnome-shell session) and http://git.gnome.org/browse/gnome-session/tree/data/gnome-fallback.session.desktop.in.in (fallback session). > (there used to be (and probably still is) a lot of racy code for ensuring that > the shell could own the name org.freedesktop.Notications ...) That won't happen at all now :-)
(In reply to comment #10) > (In reply to comment #9) > > Please explain exactly how this works with GNOME Shell where we don't want > > notification-daemon started (but we do want it for fallback mode).... > > It just won't get started in the GNOME Shell session. Compare > http://git.gnome.org/browse/gnome-session/tree/data/gnome.session.desktop.in.in > (gnome-shell session) and > http://git.gnome.org/browse/gnome-session/tree/data/gnome-fallback.session.desktop.in.in > (fallback session). > > > (there used to be (and probably still is) a lot of racy code for ensuring that > > the shell could own the name org.freedesktop.Notications ...) > > That won't happen at all now :-) Looks to me like we're basically already treating notification-daemon the way I'm suggesting that polkit-gnome-authentication-agent-1 should be treated... e.g. notification-daemon ships the mechanism (the program), while the desktop ships the policy (whether to start it or not). Only in the notification-daemon case you are not using autostart files - which is perfectly fine... Is that about right?
It's about right, yes. I don't think it's the best solution (I'd very much prefer to use an autostart file), but at least the .desktop file itself is shipped where it belongs, which matters a lot to me. (This also makes it easier for downstreams to use it as an autostart file if they prefer to deal with it this way, especially for other desktops) Are you fine shipping such a non-autostart .desktop file? If yes, I'll make sure the fallback mode uses it.
(In reply to comment #12) > It's about right, yes. I don't think it's the best solution (I'd very much > prefer to use an autostart file), but at least the .desktop file itself is > shipped where it belongs, which matters a lot to me. > > (This also makes it easier for downstreams to use it as an autostart file if > they prefer to deal with it this way, especially for other desktops) > > Are you fine shipping such a non-autostart .desktop file? If yes, I'll make > sure the fallback mode uses it. Not 100% opposed but what's the point of shipping a non-autostart .desktop file with NoDisplay=true? That gnome-session (and other desktops, presumably) can simply reference it? Why is this _extra_ indirection better? Is it just for the translations? Or because gnome-session is already set up to only work with desktop files? Or both? :-)
Both :-)
any status on this?