Red Hat Bugzilla – Bug 1000212
java-1.7.0-openjdk desktop entries very poorly named
Last modified: 2015-02-27 04:01:20 EST
Description of problem:
In java-1.7.0-openjdk.git, the desktop entries are mangled a bit, and installed after the compilation is completed:
Unfortunately, this leads to some really ugly naming. The result, if I want to override the java .desktop files to not show up in gnome-shell (I'm not sure who isn't doing this? WHY ARE THESE DESKTOP FILES EVEN EXISTENT???), I need to update the files in ~/.local/share/applications/ *every* revision or update of the pacakge. For example, after today's updates, java entries are once again showing up in my menus:
[andrew@thinkpad ~]$ ls ~/.local/share/applications/java*
[andrew@thinkpad ~]$ ls /usr/share/applications/java*
This is rather annoying - can they not simply be named something not involving the revision string? Perhaps not the uniquesuffix format?
This is likely a byproduct of our effort to move toward parallel installable RPMs (for same major Java) -- if the file names are not unique, RPM will not allow multiple installations.
I am assigning this to Jiri to see if there is another solution.
Thanks! I wonder if there is a way to strip the package version + revision information? eg, java-1.7.0-openjdk-x86_64-jconsole.desktop ?
Unfortunately that will still cause conflicts :/ We what we to allow is something like these 2 packages to co-exist:
The only uniqueness in the name there is the release string, and that is why it was added to the desktop files, as the contents of the file differ/may differ between releases and if there is a difference, RPM will refuse to allow the 2 packages to be installed in parallel uneless the file name differs.
Well the name can't be changed as Deepak explained. Also the text inside should be same, otherwise one will not recognize which jdk is lunching.
However, what is worthy to judge is" (I'm not sure who isn't doing this? WHY ARE THESE DESKTOP FILES EVEN EXISTENT???)"
tbh I have never used those programs outside the command line. But There may be people used to click them in menu, so removing them will be regression.
Also fedora guidelines says, that every gui program should have desktop entry. And those two have gui.
So unless there is serious reason to remove the entries, the bug will be closed as can't fix. Sorry.
"OpenJDK Monitoring & Management Console x86_64-18.104.22.168.fc19" is 60 characters long and results is menus being twice as wide as they would otherwise be. Aesthetics is a serious reason.
(I'm sure parallel installable JDKs will be great for some people, but I'd happily live without even one. However, when I tried to erase the OpenJDK devel pacakge yum wanted to remove the whole of LibreOffice.)
Actually, to quote the packaging guidelines ( https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#desktop-file-install_usage ), this also seems incorrect:
--vendor and desktop-file-install
For F19 and onwards, do not apply a vendor tag to .desktop files (using --vendor). New packages should not add a vendor tag to any older branches either. The vendor tag is implemented by adding a vendor prefix to the .desktop filename which breaks some tools. If an existing package has a vendor tag in previous Fedora releases it must continue to do so but only in those releases. This is mostly for the sake of user menu-editing which bases off of .desktop file/path names and thus break if the filename changes.
(In reply to Ron Yorston from comment #5)
> "OpenJDK Monitoring & Management Console x86_64-22.214.171.124.fc19" is 60
> characters long and results is menus being twice as wide as they would
> otherwise be. Aesthetics is a serious reason.
> (I'm sure parallel installable JDKs will be great for some people, but I'd
> happily live without even one. However, when I tried to erase the OpenJDK
> devel pacakge yum wanted to remove the whole of LibreOffice.)
If tooltip is supported, then this would be easily solved by sppliting the text:
text: OpenJDK Monitoring & Management Console
tool tip: x86_64-126.96.36.199.fc19
Unluckily in gnome 3 this is not working (
This is actually already prepared in desktop icons, but until gnome3 starts support it, we are out of power.
Thanks for the explanation; I unfortunately feel that this goes against packaging guidelines (as quoted above), and that Java really shouldn't get special treatment regarding co-installability of minor version updates (can you imagine if other applications did the same?), but understand the goal.
*** Bug 1140318 has been marked as a duplicate of this bug. ***
*** Bug 1181795 has been marked as a duplicate of this bug. ***
(In reply to jiri vanek from comment #4)
> tbh I have never used those programs outside the command line. But There may
> be people used to click them in menu, so removing them will be regression.
> Also fedora guidelines says, that every gui program should have desktop
> entry. And those two have gui.
Would adding NoDisplay=true be against the guidelines? Adding it might be a good way to keep the guidelines satisfied and not disturb the users.
*** Bug 1196819 has been marked as a duplicate of this bug. ***