Bug 1180819
Summary: | kde software management tool shows incorrect package description | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard Kennedy <richard> |
Component: | apper | Assignee: | Rex Dieter <rdieter> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 21 | CC: | ahughes, dantti12, dbhole, dvratil, jgrulich, jreznik, jvanek, kalevlember, kevin, ltinkl, mbriza, omajid, rdieter, rhughes, rnovacek, smparrish, than |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | apper-0.9.1-6.fc21 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-01-30 04:40:01 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: |
triaging to apper for now, but I suspect that there's an appdata oddity going on here. $ 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 ---- 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. IMHO, the best solution is to simply build Apper without AppStream support. (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. 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. 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. It comes from the .desktop file, AppStream data extraction also processes those, not just AppData. 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. 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. 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. "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: (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. "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. 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. "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? 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 But how many other packages are being hidden because apper is broken and doing the wrong thing? 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. 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. 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 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). 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. |
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