Bug 1180819 - kde software management tool shows incorrect package description
Summary: kde software management tool shows incorrect package description
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: apper
Version: 21
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-10 18:41 UTC by Richard Kennedy
Modified: 2015-01-30 04:40 UTC (History)
17 users (show)

Fixed In Version: apper-0.9.1-6.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-30 04:40:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Richard Kennedy 2015-01-10 18:41:34 UTC
Description of problem:

Searching for openjdk in the kde software management tool, does not find a package for the SDK i.e. the openjdk-devel package.

However it is there but described, somewhat obscurely as :- 

> OpenJDK 8 Monitoring & Management console

(something I have never heard of).

when in fact, it is more commonly known as the SDK or development environment, so it's very difficult to find.

'yum info *openjdk-devel*' gives the summary as 
Summary     : OpenJDK Development Environment

The KDE software management tool should use the common terminology and/or the yum summary so that users can find packages easily. 


Version-Release number of selected component (if applicable):
kde-workspace-4.11.14-3.fc21.x86_64

Comment 1 Rex Dieter 2015-01-11 00:28:02 UTC
triaging to apper for now, but I suspect that there's an appdata oddity going on here.

Comment 2 Rex Dieter 2015-01-11 01:58:00 UTC
$ appstream-index search OpenJDK
Identifier: java-1.8.0-openjdk-1.8.0.20-12.b26.fc21.x86_64-policytool.desktop [desktop]
Name: OpenJDK 8 Policy Tool 1.8.0.20-12.b26.fc21.x86_64
Summary: Manage OpenJDK policy files 1.8.0.20-12.b26.fc21.x86_64
Package: java-1.8.0-openjdk
Homepage: http://openjdk.java.net/
Icon: /usr/share/app-info/icons//fedora-21/java-1.8.0-openjdk-1.8.0.20-12.b26.fc21.x86_64-policytool.png
----
Identifier: java-1.8.0-openjdk-1.8.0.20-12.b26.fc21.x86_64-jconsole.desktop [desktop]
Name: OpenJDK 8 Monitoring & Management Console 1.8.0.20-12.b26.fc21.x86_64
Summary: Monitor and manage OpenJDK applications for 1.8.0.20-12.b26.fc21.x86_64
Package: java-1.8.0-openjdk-devel
Homepage: http://openjdk.java.net/
Icon: /usr/share/app-info/icons//fedora-21/java-1.8.0-openjdk-1.8.0.20-12.b26.fc21.x86_64-jconsole.png
----

Comment 3 Rex Dieter 2015-01-11 02:33:05 UTC
Those descriptions are coming from appstream-data, re-assigning.

May end up being expected (and WONTFIX), since appstream is tailored toward applications, and the those descriptions are valid for the applications included in those packages.

Comment 4 Kevin Kofler 2015-01-11 05:06:18 UTC
IMHO, the best solution is to simply build Apper without AppStream support.

Comment 5 Richard Kennedy 2015-01-11 12:26:19 UTC
(In reply to Rex Dieter from comment #3)
> Those descriptions are coming from appstream-data, re-assigning.
> 
> May end up being expected (and WONTFIX), since appstream is tailored toward
> applications, and the those descriptions are valid for the applications
> included in those packages.

Java has always been spilt into 2 parts, the runtime (jre) and the SDK. So naming the SDK after only one of it's apps is dumb (IMHO). How are new users going to find the Java SDK that they need for development if it's not named as such? 

The SDK contains many applications so why pick out the console for the description? If you have to use an app description at least use the most important one, the java compiler.

Better yet, call it the SDK.

Comment 6 Kevin Kofler 2015-01-11 12:35:22 UTC
The Java compiler does not fit the Fedora AppStream data generator's warped definition of "application", which includes only GUI applications. So a package with a very important command-line tool or library and some exotic GUI application that nobody used will be displayed as only that obscure GUI application.

So I stand by my comment #4: IMHO, the AppStream data is NOT useful for Apper's UI and thus we will be better off just disabling AppStream support in Apper.

Comment 7 Rex Dieter 2015-01-11 14:23:43 UTC
I've no idea where this OpenJDK-related appdata is coming from either, java-1.8.0-openjdk packaging does not provide it, as far as I can tell.

Comment 8 Kevin Kofler 2015-01-11 19:14:52 UTC
It comes from the .desktop file, AppStream data extraction also processes those, not just AppData.

Comment 9 Deepak Bhole 2015-01-12 15:30:24 UTC
The SDK is not a GUI app, nor is the JRE (java) by itself. 

It is not possible to have a .desktop file for either of them, and therefore not possible to do anything withthe OpenJDK8 RPM for this. Short of adding OpenJDK* to some sort of ignore list I am not sure sure what else we (OpenJDk RPM Maintainers) can do.

Comment 10 Rex Dieter 2015-01-12 15:34:33 UTC
What's this then?

$ rpm -ql java-1.8.0-openjdk-devel | grep desktop
/usr/share/applications/java-1.8.0-openjdk-1.8.0.25-5.b18.fc21.x86_64-jconsole.desktop

From past appdata-related discussions, I think the recommendation would be to split this "app" into it's own package.

Comment 11 Andrew John Hughes 2015-01-12 18:04:22 UTC
jconsole is the 'OpenJDK 8 Monitoring & Management console' as mentioned in the original bug. It's a GUI application provided as part of the JDK.

As some of the comments above indicate, it's more an issue with applications being defined only as GUI applications than an issue with the OpenJDK package itself. The same will be true of other packages where the main component is a library or a command-line application, and a GUI tool is provided as an optional extra.

It could be split into its own package, but java-1.8.0-openjdk would then need to depend on the new package, so users don't suddenly find jconsole has disappeared.

Comment 12 Rex Dieter 2015-01-12 18:12:32 UTC
"It could be split into its own package, but java-1.8.0-openjdk would then need to depend on the new package, so users don't suddenly find jconsole has disappeared."

Yes, that's reasonable (though in -devel subpkg), either via Requires: or Obsoletes:

Comment 13 Deepak Bhole 2015-01-12 18:31:12 UTC
(In reply to Rex Dieter from comment #12)
> "It could be split into its own package, but java-1.8.0-openjdk would then
> need to depend on the new package, so users don't suddenly find jconsole has
> disappeared."
> 
> Yes, that's reasonable (though in -devel subpkg), either via Requires: or
> Obsoletes:

I am against this sort of change. The java-1.8.0-openjdk ships numerous binary executables and we are not splitting the package for any of them. Furthermore,  we will also need to have jconsole depend on java-1.8.0-openjdk, thus making it a circular dependency. The whole reason to make this change seems to be to work around an issue with how AppStream does things.

If there is a Fedora policy on moving gui apps into their own package, then I think splitting is worth exploring. Otherwise appstream should just add openjdk to some sort of ignore list. The above mentioned split won't solve the problem anyway as a search for openjdk will still not show the sdk.

Comment 14 Rex Dieter 2015-01-12 18:36:03 UTC
"The above mentioned split won't solve the problem anyway as a search for openjdk will still not show the sdk."

Yes, it will.  Right now, apper is prefering the appstream data for the jconsole application, rather than displaying the -devel pkg info.

If they were split, apper would/could show them separately.

Comment 15 Andrew John Hughes 2015-01-12 18:40:27 UTC
Maybe AppStream could be made more intelligent, so that if, for example, the majority of executables in a package don't have corresponding .desktop files, the package is automatically excluded?

I tend to agree with Deepak that adding a separate package for a couple of files is not a good idea, and we already avoided doing something similar for the soundfont dependency (hence the potentially dangling symlink in the JDK). There are already a large number of java-x.x.x-openjdk-* packages, especially with the introduction of the headless package, and we don't need another just to work around what appears to be an application bug.

Comment 16 Andrew John Hughes 2015-01-12 18:43:21 UTC
"Right now, apper is prefering the appstream data for the jconsole application, rather than displaying the -devel pkg info."

Then, why not just have it use the package information to begin with? Or do packages appear multiple times if they contain multiple .desktop files?

Comment 17 Rex Dieter 2015-01-12 19:19:10 UTC
From what I can gather,

* appstream assumes one application per package (apparently)
* apper prefers to display appstream data, if available (over pkg info)
(I'm only the messenger, I cannot comment on the wisdom of the design)


OK, from your choices:
* make jconsole subpkg
* blacklist jconsole from appstream data 
* do nothing

If you choose blacklist, mention that and reassign to appstream-data package.
If you choose nothing, feel free to close WONTFIX

Comment 18 Richard Kennedy 2015-01-13 12:45:07 UTC
But how many other packages are being hidden because apper is broken and doing the wrong thing?

Comment 19 Rex Dieter 2015-01-13 13:08:36 UTC
As Kevin suggested in comment #4, another option is too drop appstream support from apper, at least until packaging (and perhaps appstream design) can be improved.  I personally would rather not do that, since it would hinder making progress in making appstream support (in fedora) better.

Regardless if that happens or not, I have identified a few other packages affected (in addition to jconsole) and will continue advocating:
* their packaging be improved (usually to create 'one package per application') 
or
* these applications be blacklisted
to accommodate (current) appstream design.

Comment 20 Rex Dieter 2015-01-13 16:25:52 UTC
Update: in kde-sig meeting today, we agreed to disable appstream support in apper, for now.  It's implementation is not great, and there are too many problematic packages.

Re-assigning (back) to apper.


I would continue to openjdk maintainers to consider implementing one-app-per-package for the future.

Comment 21 Fedora Update System 2015-01-13 17:55:06 UTC
apper-0.9.1-6.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/apper-0.9.1-6.fc21

Comment 22 Fedora Update System 2015-01-14 07:32:41 UTC
Package apper-0.9.1-6.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing apper-0.9.1-6.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-0681/apper-0.9.1-6.fc21
then log in and leave karma (feedback).

Comment 23 Fedora Update System 2015-01-30 04:40:01 UTC
apper-0.9.1-6.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.