getting rid of vendor prefixes for desktop files

Michael Schwendt mschwendt at gmail.com
Wed May 21 07:31:41 UTC 2008


On Tue, 20 May 2008 13:18:43 -0400, Matthias Clasen wrote:

> I'd like to discuss the idea of getting rid of vendor prefixes for
> desktop files in Fedora. Right now, we install desktop files with a
> mixture of vendor prefixes: gnome-, fedora-, redhat-, nothing. 
> 
> These prefixes really add no value, and cause actual breakage, since
> Fedora is (afaik) the only distro adding vendor prefixes, so we are the
> ones that get bitten by upstream changes that don't take vendor prefixes
> into account. 
> 
> The recent breakage that made me write this mail is that the new
> gnome-session in rawhide has a list of mandatory session components
> stored in gconf, and one of these components was 'nautilus', so it went
> looking for nautilus.desktop - which doesn't exist, since we ship
> gnome-nautilus.desktop.
> 
> Another problem caused by these prefixes is that overlaying a self-built
> gnome, e.g. a jhbuild tree on top of a fedora installation gives you
> everything doubled in the menus. Once with a vendor prefix, and once
> without, instead of the indended effect of the self built tree hiding
> the installed desktop files.
> 
> Thus, I'd like to propose that we change the packaging guidelines to
> stop recommending the addition of a vendor prefix, and remove existing
> vendor prefixes in F10. This will cause a mild one-time pain for
> existing users with customized menus. We can probably discuss ways to
> avoid that.
> 
> Comments ?

What have you planned to avoid messing up user's panel and menu?

For example, emacs-22.2-4.fc9 suddenly decided to ship emacs.desktop
instead of the earlier gnu-emacs.desktop. This invalidated the GConf
setting for my customised panel where I had dragged'n'dropped the
emacs menu entry:

panel/objects/object_3/%gconf.xml:                <stringvalue>/usr/share/applications/gnu-emacs.desktop</stringvalue>

Instead of the application icon it shows a blank area now.

It's not the first time this has happend with a package. And it really
asks for a stable vendor prefix (even if empty). Else this is much too
fragile during upgrades and updates if packagers and upstream can
change the vendor prefix whenever they like.




More information about the devel mailing list