Rationale
To the best of my knowledge, the issue is this:
- At this moment, the Packaging Guidelines say:
"If upstream uses <vendor_id>, leave it intact, otherwise use fedora as <vendor_id>."
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.
Proposed New "desktop-file-install usage" section
desktop-file-install usage
It is not simply enough to just include the .desktop file in the package, one MUST run desktop-file-install OR desktop-file-validate in %install (and have BuildRequires: desktop-file-utils), to help ensure .desktop file safety and spec-compliance. desktop-file-install 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). desktop-file-validate 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).