Bug 1000212

Summary: java-1.7.0-openjdk desktop entries very poorly named
Product: [Fedora] Fedora Reporter: abrouwers
Component: java-1.7.0-openjdkAssignee: jiri vanek <jvanek>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: ahughes, dbhole, jerboaa, jvanek, mhroncok, omajid, rc040203, rmy, rverschelde
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-28 11:50:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description abrouwers 2013-08-23 00:49:08 UTC
Description of problem:

In java-1.7.0-openjdk.git, the desktop entries are mangled a bit, and installed after the compilation is completed:

http://pkgs.fedoraproject.org/cgit/java-1.7.0-openjdk.git/tree/java-1.7.0-openjdk.spec#n774

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*
/home/andrew/.local/share/applications/java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc19.x86_64-jconsole.desktop
/home/andrew/.local/share/applications/java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc19.x86_64-policytool.desktop

[andrew@thinkpad ~]$ ls /usr/share/applications/java*
/usr/share/applications/java-1.7.0-openjdk-1.7.0.25-2.3.12.4.fc19.x86_64-jconsole.desktop
/usr/share/applications/java-1.7.0-openjdk-1.7.0.25-2.3.12.4.fc19.x86_64-policytool.desktop


This is rather annoying - can they not simply be named something not involving the revision string?  Perhaps not the uniquesuffix format?

Comment 1 Deepak Bhole 2013-08-23 20:37:21 UTC
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.

Comment 2 abrouwers 2013-08-23 20:41:19 UTC
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 ?

Comment 3 Deepak Bhole 2013-08-23 20:50:39 UTC
Unfortunately that will still cause conflicts :/ We what we to allow is something like these 2 packages to co-exist:

java-1.7.0-openjdk-1.7.0.25-2.3.12.2.fc19.x86_64
java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc19.x86_64

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.

Comment 4 jiri vanek 2013-08-27 16:14:07 UTC
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.

Comment 5 Ron Yorston 2013-08-27 21:22:48 UTC
"OpenJDK Monitoring & Management Console x86_64-2.3.12.4.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.)

Comment 6 abrouwers 2013-08-27 23:15:08 UTC
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.
"

Comment 7 jiri vanek 2013-08-28 09:13:51 UTC
(In reply to Ron Yorston from comment #5)
> "OpenJDK Monitoring & Management Console x86_64-2.3.12.4.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-2.3.12.4.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.

Comment 8 abrouwers 2013-08-28 12:04:49 UTC
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.

Comment 11 jiri vanek 2014-09-11 07:30:47 UTC
*** Bug 1140318 has been marked as a duplicate of this bug. ***

Comment 12 jiri vanek 2015-01-26 11:58:33 UTC
*** Bug 1181795 has been marked as a duplicate of this bug. ***

Comment 13 Miro HronĨok 2015-01-27 12:08:41 UTC
(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.

Comment 14 jiri vanek 2015-02-27 09:01:20 UTC
*** Bug 1196819 has been marked as a duplicate of this bug. ***