GNOME Bugzilla – Bug 330397
autostart uses config_dir instead of data_dir
Last modified: 2006-03-01 15:55:08 UTC
The current code uses the config_dir functions instead of data_dir, so it looks to /etc/xdg/autostart. It should probably rather use /usr/share/autostart
Created attachment 58928 [details] [review] use data_dir instead of config_dir
Hi, While data_dir makes more sense, the writers of the autostart spec chose config_dir, and using /usr/share/autostart would actually clash with kde which has been using that directory for years from something incompatible with autostart.
Apps like gnome-volume-manager do install their .desktop to /usr/share/autostart and that doesn't work with the current gnome-session. What is the issue to use the same folder as KDE for autostarting? We can require X-GNOME-Autostart-enabled=true or use OnlyShowIn if we don't want to start KDE applications from GNOME by example. Does installing .desktop to /etc respect the FHS specification? If you don't want to use the same folder has KDE what about using /usr/share/gnome-autostart so?
Hi, I wasn't part of the xdg-list discussion when the autostart spec was created. I assume its intentions were to create a common directory for both KDE and GNOME to do autostart from. The directory picked was $XDG_CONFIG_DIRS/autostart. It seems like an unfortunate choice and I don't know the history of why that particular location was picked. Using /usr/share/autostart would also be a poor choice, in my opinion, because KDE already uses it for something incompatible. KDE already installs desktop files there that don't have OnlyShowIn keys in them for instance. It also installes desktop files there that are unrelated and don't have Exec= lines. It might make sense to use a new directory, say /usr/share/startup, that follows the semantics specified in the spec, and doesn't have legacy compatibility issues. The spec would need to be updated, however, before that could be fixed. Alternatively, we could just ignore the spec-which I don't think KDE uses either-and just come up with our own thing (like your example, /usr/share/gnome-autostart). Or we could just drop the whole thing and finish the work Mark started on the new session manager thing. gnome-volume-manager installing into /usr/share/autostart is just wrong though. /usr/share/autostart is already being used by KDE and it will just break things.
Also, the autostart stuff is Rodrigo's code, so what happens should really be his call, I guess...
The /etc folder is just not the right place to install that datas. At the moment we use /usr/share/autostart for gnome-session on Ubuntu and the KDE maintainers has patched the KDE packages to use OnlyShowIn=KDE. I'll update gnome-session to ignore the .desktop specific to KDE next. You say that KDE puts different kind of .desktop to that folder, but that's for the same purpose. Why not just fixing to spec to use that place and making KDE follow the specific, that would be trivial changes for them
Hi, I agree /etc is not the right place for these files. I also agree that the spec should be changed to use a directory in /usr/share. I also agree, that if the spec is changed to use /usr/share/autostart, then gnome-session should be changed to use that directory. I think, however, it's a bad idea to use /usr/share/autostart, because it will mean that an old KDE installation will hose a new GNOME installation. A user could conceivably upgrade to the latest GNOME, try to login and get a KDE panel and konquerer file manager running in their GNOME session. That's just broken. Maybe it could use /usr/share/autostart if the spec provided some mechanism for GNOME to ignore old kde-installed .desktop files. Regardless, gnome-session should either follow the spec or completely do its own thing. It shouldn't do some halfway in-between, sort of follows the spec, thing.
Using /etc is wrong and /usr/share/autostart gives a lot of problems in systems with KDE installed. So, until all desktops implement the specification, I'd change it to /usr/share/startup or something that way. Thus even though we won't conform to the (wrong in this aspect) spec, we won't break the FHS and will avoid pain for users with KDE also installed. g-v-m and others need to be changed once we decide which dir to use. So, Ray, if you've got nothing against this, we'll change it to /usr/share/startup ok?
That issue still exists with 2.13.91 and now different applications use different place for that, could we make a call for one place?
I personally think the fd.o spec is wrong by using XFG_CONFIG_DIRS.
What do fedora and suse do about that at the moment? For Ubuntu we have patched gnome-session to use /usr/share/autostart and KDE .desktop for that, but that would be better to get that fixed upstream. GNOME 2.13.92 tarball are due today, could we get that sorted?
suse uses $prefix/share/autostart, whihc is /opt/gnome/share/autostart. Ray, what do you think? Should we leave it as it is, thus conforming to the spec, or should we change to the better IMO $datadirs?
I'm okay with changing it to datadirs as long as people who upgrade to gnome 2.14 (but don't touch their kde installation), don't get a kde panel and konquerer window when they log into gnome. If we change it, we're basically saying "We don't like the spec, so until it's fixed we're going to do our own thing". That's fine with me, but we shouldn't try to conflict with the spec or existing practice (kde). So let's move it to /usr/share/gnome/autostart. No conflicts there, doesn't stomp all over kde, etc. Note, we don't have that much time left, so Rodrigo, if you're going to make the change, you should make it soon.
Created attachment 60237 [details] [review] committed patch This is what I've committed
Hi, I would support both paths this late in the release. Things are going to break otherwise.
This is not going to work. You can not just change paths at this point in the release process; we are already in RC area
Only a few programs, all in the desktop release, use this, and some of them didn't even update to the /etc/xdg prefix, AFAIK. So, isn't it easier to just fix those few packages? I already sent a patch for gnome-power-manager and will be doing the same for other modules
You know that we are a few days away from FC5, right ? We fixed those apps in FC5 to use /etc/xdg...
Can't we just patch those apps again? AFAICS, there are just a few. Which ones did you fix?
In fact, just had a look at my whole CVS tree, and only found gnome-power-manager to use this, and it's already patched to use the new dir. So, closing.
Sure we can patch all apps again. We can also stop being silly, and respect the release schedule.
And where is $(datadir)/gnome/autostart dir now? It is not installed by gnome-session.
Sorry for being silly, but again, only gnome-power-manager used the old dir, and it is already patched, so why do we need to support the old directory? Could you let me know what other apps are affected? Fryderik: gnome-session does not install any .desktop file there, so it doesn't create the dir. It is the apps that use the mechanism (like gnome-power-manager) that create it if it doesn't exist when copying their .desktop files there.
(In reply to comment #23) > Fryderik: gnome-session does not install any .desktop file there, so it doesn't > create the dir. It is the apps that use the mechanism (like > gnome-power-manager) that create it if it doesn't exist when copying their > .desktop files there. gnome-session does not install any .desktop file but provides autostart service for other apps. It should also provide autostart dir (like hicolor-icon-theme provides dirs for other apps, etc.)
Rodrigo, NetworkManager, beagle, and krb5-auth-dialog also use the autostart dir, which even though they aren't part of GNOME 2.14 are still important to not break as they are parts of FC5. There might be other apps that use it which I don't have installed and don't know about. As for why we need to support the old directories, it's in the spec and in the previous releases of gnome-session. Additionally, your name is on the spec as an author; take responsibility for your work. I know that it isn't entirely your fault, but next time, avoid this mess by writing a better spec. ;-)
Is there any reason why NM and beagle don't have their autostart stuff in CVS?
You're probably not looking hard enough. NM does for sure, and I don't know why beagle wouldn't. We're using the latest release stock.
right, I had a wrong branch for NM, but, hey, it's using the wrong dir: autostartdir = $(datadir)/autostart Sending a patch right now for it.