TomCallaway/DesktopFileVendor

Rationale
To the best of my knowledge, the issue is this:

"If upstream uses , leave it intact, otherwise use fedora as ."
 * At this moment, the Packaging Guidelines say:

See: https://fedoraproject.org/wiki/Packaging/Guidelines#desktop-file-install_usage

Really, I suspect that we no longer want to use a vendor ID at all. I think that the upstream specification is flawed in this area, and it causes more trouble than it is worth.

This would only apply to new packages, because I do not think there is anyway to avoid destroying menus for .desktop files which use the vendor tag. If there were a way to drop it altogether, I don't think you'd get any complaints.

desktop-file-install usage
It is not simply enough to just include the .desktop file in the package, one MUST run  OR   in   (and have  ), to help ensure .desktop file safety and spec-compliance. MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of usage:

desktop-file-install                                   \ --dir=${RPM_BUILD_ROOT}%{_datadir}/applications        \ %{SOURCE3}

desktop-file-install                                   \ --add-category="Multimedia"                            \ --delete-original                                      \ --dir=%{buildroot}%{_datadir}/applications             \ %{buildroot}/%{_datadir}/applnk/Multimedia/foo.desktop

desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop


 * For new packages, do not apply a vendor tag to desktop files. Existing packages that use a vendor tag must continue to do so for the life of the package. This is mostly for the sake of menu-editing (which bases off of .desktop file/path names).