Bug 1098735 - apper: PackageKit-hif (hawkey) backend missing comps group support
apper: PackageKit-hif (hawkey) backend missing comps group support
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: apper (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Josh Munilla
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, FutureFeature, Reopened
: 1178146 1215851 1297708 1357986 (view as bug list)
Depends On:
Blocks: pk-hif-features F21Blocker-kde 1098218
  Show dependency treegraph
 
Reported: 2014-05-17 15:58 EDT by Rex Dieter
Modified: 2018-02-16 16:59 EST (History)
31 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-02-16 14:35:21 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2014-05-17 15:58:09 EDT
Testing hawkey backend with apper on f20 at least, whenever I try to browse Categories to install anything new, packagekit reports an error:
"This function is not yet supported"

Which is the error string associated with
Transaction::InternalErrorFunctionNotSupported

Need to verify this gets fixed for f21 when default backend gets flipped to hawkey
Comment 1 Rex Dieter 2014-05-17 16:02:55 EDT
Fwiw, on f20, installing regular updates *mostly* works, just get an occasional packagekitd crasher though, bug #1057843
Comment 2 Fedora Blocker Bugs Application 2014-05-17 16:16:20 EDT
Proposed as a Blocker for 21-beta by Fedora user rdieter using the blocker tracking app because:

 Installing updates via apper known to crash packagekitd occasionally.  As a bonus (yay), currently, hawkey backend apparently lacks some feature(s) apper needs to be able to browse categories (and install software).
Comment 3 Kevin Kofler 2014-05-17 17:43:32 EDT
Shouldn't this be filed against PackageKit (i.e. the main package from which PackageKit-hawkey is built)?
Comment 4 Rex Dieter 2014-05-17 17:53:40 EDT
oops, right.  reassigning->PackageKit
Comment 5 Richard Hughes 2014-07-08 11:04:33 EDT
Someone from KDE is going to need to write this code then, nothing other than apper needs this functionality now. Hawkey and librepo do not parse the comps metadata, and the library that does (libcomps iirc) isn't integrated into the hawkey backend. Apper really should switch to getting the groups list from the AppStream metadata now.
Comment 6 Kevin Kofler 2014-07-08 12:05:49 EDT
Sigh… It's your backend that is not implementing the required interfaces just because GNOME Software happens not to use them, and now you want somebody else to do the work for you? :-(
Comment 7 Richard Hughes 2014-07-09 04:32:46 EDT
(In reply to Kevin Kofler from comment #6)
> Sigh… It's your backend that is not implementing the required interfaces

No. The GetCategories method is always optional. Not all backends support it, and PackageKit clients are supposed to gracefully fall back to something else (e.g. GetGroups) if a required method isn't available.

> just because GNOME Software happens not to use them, and now you want
> somebody else to do the work for you? :-(

Look at this point of view instead: Why should I do several weeks of work for a desktop evironment I don't use when there's a supported way of doing something (AppStream) that everyone has agreed is the way forward? Apart from compose, comps isn't going to be needed at all in the workstation image now we are only shipping the live image.

Ohh, and another thing. Please stop spreading FUD[1] about AppStream. AppStream 0.7+ (as shipped in rawhide) is valid XML (i.e. xmllint validates it). There are also a quite few KDE applications supporting AppData, and Matthias has been working with lots of KDE upstreams slowly merging in files. AppStream shows KDE apps just fine, if upstream sets a "Comment" in the desktop file, or sets a "summary" in the AppData file. Expecting a 48px icon isn't exactly a suprising  requirement. Have a look here for some other requirements, although I'm sure they'll make you upset: https://github.com/hughsie/appstream-glib#guidelines-for-applications

Richard.

[1] http://meetbot.fedoraproject.org/fedora-meeting/2014-07-08/kde-sig.2014-07-08-15.09.log.html
Comment 8 Adam Williamson 2014-07-10 00:40:27 EDT
the back and forth is all well and good (popcorn, please, butler!), but apper not working is still a Beta release blocker bug, so we either need this reopened and re-assigned to apper, or a new bug opened.
Comment 9 Kevin Kofler 2014-07-10 06:49:11 EDT
> Have a look here for some other requirements, although I'm sure they'll make
> you upset:

That link is where the ones I complained about come from.

In any case, as Adam says, NOTABUG is not the right answer, we need to either get the feature added to PackageKit-hawkey/hif or to get Apper changed to use something different.

Daniel, if we get AppStream support fully working in Apper, will it then still need GetCategories?
Comment 10 Rex Dieter 2014-09-12 14:08:27 EDT
Discussed a bit with dantti on irc today, there are 2 avenues to pursue here:
* leverage appstream metadata for groups (somehow) in apper (preferred)
* implement comps/groups support in PK hawkey backend

dantti mentioned he likely would not have time to work on this (much) prior to F21 beta change deadline of Oct 14.  I'll try to poke ximion (aka Matthias Klumpp) to see if this is something he could help with (or otherwise offer advice).
Comment 11 Kevin Kofler 2014-09-16 11:22:16 EDT
There are actually 4 sets of functions (functions or pairs of functions) that are missing:
1. GPG key autoimport: pk_backend_install_signature
2. Dependency querying: pk_backend_depends_on, pk_backend_required_by
3. Category (comps group) support: pk_backend_get_categories, pk_backend_search_groups
4. FedUp upgrades: pk_backend_get_distro_upgrades

The biggest problem for Apper is set 3. Set 2 missing means less information in Apper's package details. Set 1 will be a suboptimal user experience for everyone using third-party repositories (for which we cannot preimport the GPG keys in our kickstarts for obvious reasons). Set 4 is nice-to-have, but will only really matter once Fedora 22 releases, and it last worked with PreUpgrade (the yum backend never got FedUp support).
Comment 12 Richard Hughes 2014-09-17 05:49:48 EDT
(In reply to Kevin Kofler from comment #11)
> There are actually 4 sets of functions (functions or pairs of functions)
> that are missing:
> 1. GPG key autoimport: pk_backend_install_signature

We don't actually need this; libhif autoimports keys already installed in /etc/pki/rpm -- there's no security benefit at all for querying. If your /etc is already compromised, autoimporting a signature is the last of your problems.

> 2. Dependency querying: pk_backend_depends_on, pk_backend_required_by

We can certainly do pk_backend_depends_on() and pk_backend_required_by() for installed packages, but for not installed packages implementing this becomes a bit fuzzier.

> 3. Category (comps group) support: pk_backend_get_categories,
> pk_backend_search_groups

We'd need comps support in libhif for this; this isn't a small amount of work although something we may have to do in the long run.

> 4. FedUp upgrades: pk_backend_get_distro_upgrades

This would be easy to add, if someone tells me the new URL for the upgrade information.

Richard
Comment 13 Kevin Kofler 2014-09-17 18:35:12 EDT
ad 1. The reason RPM doesn't just auto-import everything in /etc/pki/rpm as you're now doing is not that keys in /etc could be compromised, but that they could be valid e.g. only for testing packages, which the administrator may or may not want to trust.

ad 2. The recursive case is indeed complicated (does anybody actually use that?), but aren't the non-recursive versions what is displayed by Apper in the package information? There I just expect a full unfiltered list of what amounts to "repoquery --requires foo" resp. "repoquery --whatrequires --alldeps foo". The first is just a hy_package_get_requires. For the second, we need a hy_query_filter_reldep_in(…, HY_PKG_REQUIRES, hy_package_get_provides(…)).

ad 3. I know. This (missing comps support) is the main issue for us now, I have been looking into what it'd take to implement this, I'm just not sure yet that I'll be able to pull it off in the 1 month we have until Beta. I know we need to fetch the comps.xml file(s) from the repo(s) (ideally, librepo should be able to do that for us, we may have to add that functionality there) and then feed it to libcomps.

ad 4. You need to talk to the FedUp folks about that. This is lowest on my personal list of priorities.
Comment 14 Richard Hughes 2014-09-18 11:13:53 EDT
(In reply to Kevin Kofler from comment #13)
> ad 1. The reason RPM doesn't just auto-import everything in /etc/pki/rpm as
> you're now doing is not that keys in /etc could be compromised, but that
> they could be valid e.g. only for testing packages, which the administrator
> may or may not want to trust.

Are test packages typically signed with a different key these days?

Richard.
Comment 15 Tim Lauridsen 2014-09-24 01:42:13 EDT
(In reply to Kevin Kofler from comment #13)

> 
> ad 3. I know. This (missing comps support) is the main issue for us now, I
> have been looking into what it'd take to implement this, I'm just not sure
> yet that I'll be able to pull it off in the 1 month we have until Beta. I
> know we need to fetch the comps.xml file(s) from the repo(s) (ideally,
> librepo should be able to do that for us, we may have to add that
> functionality there) and then feed it to libcomps.
> 

dnf uses libcomps to handle groups/categories, it don't need a lot of clue code to just the read the categories, groups and the packages in the groups.

Installing groups like objects is another story
Comment 16 Kevin Kofler 2014-09-24 06:47:55 EDT
To be frank, I don't care about GroupAsObjects. :-) I personally don't have that (mis)feature enabled to begin with, and I don't think it missing is a blocker in any way. What we need for Apper is to be able to browse the groups and select individual packages from there.

PackageKit also supports having the group in the package list as a (meta)package when you search for packages, that should not be hard to add either when we're adding comps support anyway, but the effect of that is just to install the mandatory and default packages. IMHO, that is good enough.
Comment 17 Kevin Kofler 2014-09-24 06:50:42 EDT
PS: Also keep in mind that PackageKit-hif and DNF only share the Hawkey layer. If the list of installed GroupsAsObjects is managed in the DNF layer, PackageKit cannot know about it. So that's one more reason why I don't think that that DNF feature matters for PackageKit-hif.
Comment 18 Tim Lauridsen 2014-09-24 07:12:56 EDT
(In reply to Kevin Kofler from comment #17)
> PS: Also keep in mind that PackageKit-hif and DNF only share the Hawkey
> layer. If the list of installed GroupsAsObjects is managed in the DNF layer,
> PackageKit cannot know about it. So that's one more reason why I don't think
> that that DNF feature matters for PackageKit-hif.

Agree, dnf features, dont matter for PackageKit-hif, but it shows that libcomps has the needed functionality to get the work done. PackageKit-hif just need to use it, to gain the category/group support.
Comment 19 Adam Williamson 2014-10-01 13:03:42 EDT
Discussed at 2014-10-01 blocker review meeting - http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-01/f21-blocker-review.2014-10-01-15.58.log.txt . This bug seems somewhat complicated. For Beta, the criteria require only graphical *updating* to work, and so far as we can tell from this bug, it more or less does:

"Installing updates via apper known to crash packagekitd occasionally."

it sounds like the update basically works, but you get a PK crash notification. That doesn't seem serious enough to block the release.

If this impression is incorrect, could you please file a *separate* bug that covers only the update problem, and avoids all the popcorn stuff about categories and groups-as-objects and whatever, and nominate that one as a Beta blocker? It would make things clearer.

The other issues covered in this bug we thought may be considered to block Final under the 'default applications must work' criterion, so we are taking the liberty of re-proposing it for Final.
Comment 20 Rex Dieter 2014-10-01 14:47:42 EDT
I'll retest the updating part specifically, and report back.
Comment 21 Kevin Kofler 2014-10-01 20:05:53 EDT
Another question: Is it possible to install new packages by searching for them by name, or does that also not work?
Comment 22 Branko Grubić 2014-10-02 15:42:58 EDT
I did some testing today, installed 'Fedora-Live-KDE-x86_64-21_Alpha-1.iso' (it is alpha_rc1, which is the same image as alpha release?), first I did manually with 'yum check-update' (not sure can this affect 'apper' in some way? I think it doesn't 'PackageKit' was missing at the time, later added as dep to 'PackageKit-Qt'), and after this, I did 'yum update PackageKit-Qt' to get needed dep, to be able to test this. Restarted my sytem.

(I'm not sure how this is important, I think I tried to search for packages first, before this, which maybe triggered packagekitd to get metadata...) 
Apper pop-up shows up and says that update are available (I think it even tries to list them in pop-up/notification), I said "review" instead of install, and it opened a window, listed all updates, so I updated my system with apper, it worked mostly ok, and updated my system.

(In reply to Kevin Kofler from comment #21)
> Another question: Is it possible to install new packages by searching for
> them by name, or does that also not work?

It is possible to search for package by its name, so I tested this by searching for 'kate' it listed multiple packages with 'kate' in its name, and I selected 'kate' (text editor) for install, and installed it. This also worked OK.




Generic package groups are listed (fallback mode), but you cannot search inside specific group, missing packagekit feature.
Comment 23 Kevin Kofler 2014-10-04 16:29:44 EDT
So, from the complaints from the blocker proposal for F21 Beta (comment #2):

> Installing updates via apper known to crash packagekitd occasionally.

This part seems resolved, it was apparently simply a bug, not a missing feature.

> As a bonus (yay), currently, hawkey backend apparently lacks some feature(s)
> apper needs to be able to browse categories (and install software).

This one is still current. So let's focus on the original issue here, which was about this particular problem, and which is due to PackageKit-hif not implementing the pk_backend_get_categories and pk_backend_search_groups functions. Any other not yet implemented stuff (see comment #11) is not critical. If we want to track the other missing functions, we should file separate RFEs against PackageKit for them.
Comment 24 Stephen Gallagher 2014-11-05 11:22:20 EST
Just a polite reminder; this bug is currently proposed as a Final Blocker and we are getting fairly close to Final Freeze (November 18th). Could we get a status update here?
Comment 25 Kamil Páral 2014-11-05 12:18:06 EST
Discussed at 2014-11-05 blocker review meeting [1]. Rejected as a blocker, but accepted as a freeze exception. This bug isn't a clear violation of the criteria but a fix would be considered during freeze.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-05/
Comment 26 Helio Chissini de Castro 2014-11-10 13:26:19 EST
Update on matters.

Talks with hughsie, we found a proper path to get a solution, and we will be working on that ASAP.
Comment 27 Adam Williamson 2014-12-05 14:44:36 EST
21 is done, cleaning blocker process metadata.
Comment 28 Kevin Kofler 2014-12-10 22:39:36 EST
Fix under upstream review: https://github.com/hughsie/PackageKit/pull/20
Comment 29 Rex Dieter 2015-01-02 10:28:51 EST
*** Bug 1178146 has been marked as a duplicate of this bug. ***
Comment 30 Matthew 2015-01-18 10:16:08 EST
I ran an upgrade of Fedora 20 to Fedora 21 today using Fedup with the"nonproduct" option as I wanted to maintain my KDE based setup from fedora 21.

The upgrade process went through with no errors shown, but when I booted into the new build and checked Apper, I found it was no longer working fully.

I now find that in Apper I can see the list of installed software and I can look for the list of updates and apply them, but within the groups section, those groups are just empty when you open them up.  So I can't search through the groups to find new software.

At first I was getting a search error when trying to open a specific group in Apper, but after Apper found more updates after the initial fedora 21 upgrade, this error no longer shows up, but the groups are still empty.
 
Searching for software by name in Apper seems to be very slow, in fact it seems to get locked into a loop. I have just now tested a search for software I know is on this system and it resulted in nothing being found and the search wasn't cancel-able, I had to close Apper.


Has Apper been superseded by another utiliity in Fedora 21?  
I though I read something a while back to suggest Apper was on it's way out in Fedora 21.
Comment 31 Kevin Kofler 2015-01-18 18:34:48 EST
> Has Apper been superseded by another utiliity in Fedora 21?  

No. This is not even Apper's fault, but PackageKit-hif's. The fix is still pending approval for upstream PackageKit-hif.
Comment 32 Elia Devito 2015-02-07 12:00:30 EST
@Richard Hughes

Can you please merge the patch and fix packagekit hif backend?
there isn't only gnome
Comment 33 Rob Di Leo 2015-04-26 16:04:43 EDT
Has anything been done to fix this bug?  I've tried several things mentioned on several sites, but nothing has worked yet.
Comment 34 Branko Grubić 2015-04-27 01:06:01 EDT
(In reply to Rob Di Leo from comment #33)
> Has anything been done to fix this bug?  I've tried several things mentioned
> on several sites, but nothing has worked yet.

As you can see from comment #28 code is available, waiting to be merged to PackageKit.
If you follow the link you can find it is now a different pull request but with the same inital code + requested fixes  
https://github.com/hughsie/PackageKit/pull/49
Comment 35 Rex Dieter 2015-04-28 09:36:11 EDT
*** Bug 1215851 has been marked as a duplicate of this bug. ***
Comment 36 Shawn 2015-04-28 16:37:54 EDT
Heh. Thanks for the great work as always!  I don't think we can say often enough how much it is appreciated.
Comment 37 Shawn 2015-07-31 09:27:29 EDT
(In reply to Branko Grubić (bitlord) from comment #34) 
> As you can see from comment #28 code is available, waiting to be merged to
> PackageKit.
> If you follow the link you can find it is now a different pull request but
> with the same inital code + requested fixes  
> https://github.com/hughsie/PackageKit/pull/49

Following your link, the last time anything was even said there was on March 31, which leads me to believe that nothing is being done about this.  Am I wrong (hopefully)?  Without the categories it does make apper pretty useless.  So, the kde spin is effectively without a working package manager gui.
Comment 38 Carsten P. 2015-09-30 16:31:42 EDT
Installed f22 on new Hardware 6 weeks ago.
I was used to use yum with yumex before and was surprised that a new default software management is unable to show packages correct in KDE.

But I was glad to see that the bug is known and it looked like a solution is ready, but looks like nothing happens in near future.

I loaded yumex now again as it is still able to show the groups and makes my f22 much more useful...
Comment 39 Fedora End Of Life 2015-11-04 05:21:53 EST
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 40 Shawn 2015-11-04 08:01:08 EST
I am (unfortunately) able to still reproduce this the current version of Fedora (23).  This should be updated to reflect that, so that the report does not disappear.  AFAIK, I cannot do this.
Comment 41 Rex Dieter 2015-11-04 08:05:17 EST
marking as FutureFeature to avoid autoclose
Comment 42 Adam Williamson 2015-11-04 13:13:27 EST
I thought the idea was to switch to muon?
Comment 43 Rex Dieter 2015-11-04 13:16:38 EST
We wanted to *add* muon as a software center, but to keep apper for package management and PackageKit session interface (even if that doesn't work all that well in recent releases)
Comment 44 Shawn 2015-11-04 14:54:45 EST
Off topic I guess, but my two cents:  Muon Package Manager works well for package management, although I have no idea if it is maintained.  I find discover painful.
Comment 45 Rex Dieter 2015-11-04 15:07:12 EST
muon as distributed by kde.org in plasma releases... includes only muon discover and muon updater
Comment 46 Michael Catanzaro 2015-11-04 15:26:28 EST
Regardless, there are five minor comments left on the upstream pull request, so this would probably be an easy project to finish off, if anyone from KDE wants to complete it. It's unlikely to happen otherwise.
Comment 48 Rex Dieter 2016-01-12 07:39:45 EST
*** Bug 1297708 has been marked as a duplicate of this bug. ***
Comment 49 vafr 2016-02-22 15:06:09 EST
So?

I appreciate that the the gods discuss the miserable matters of fact but the lesser men that are not able to follow this discussion anymore are confronted with malfunctioning apper distributed in the KDE fedora spin.

Without trowing mud, can any of the gods advise to use muon instead? Or yumex-dnf? Or perhaps advise to say goodbye to KDE and/or Fedora all together ?
Comment 50 vafr 2016-02-22 15:15:26 EST
uname -a
Linux 4.3.5-300.fc23.x86_64 #1 SMP Mon Feb 1 03:18:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Comment 51 Rex Dieter 2016-07-19 14:20:25 EDT
*** Bug 1357986 has been marked as a duplicate of this bug. ***
Comment 52 SBB 2016-11-22 16:02:11 EST
Still able to reproduce in Fedora release 25.
Comment 53 JNoake 2018-02-16 10:48:58 EST
Still able to reproduce in Fedora release 27.

Is there a GUI package tool for KDE that has superseded Apper? ... you know, that works from a users perspective?

I find it difficult to believe that such fundamental functionality is missing from KDE.

Anyone who depends on GUI assistance is going to give up on KDE just because of this!
Comment 54 Kevin Kofler 2018-02-16 10:58:35 EST
> Is there a GUI package tool for KDE that has superseded Apper? ... you know, that
> works from a users perspective?

Dnfdragora is the recommended package management tool nowadays. It is toolkit-agnostic, using libyui, which can use Qt, GTK+ and ncurses under the hood.

There is also Plasma Discover, which is more like GNOME Software (application-centric, using AppStream), but which may also fit your needs.

Both are installed by default on the current versions of the Fedora KDE Spin.
Comment 55 Shawn 2018-02-16 14:22:48 EST
(In reply to JNoake from comment #53)
> 
> 
> I find it difficult to believe that such fundamental functionality is
> missing from KDE.
> 

Just to be clear, the flaw is not a flaw of KDE, but rather Fedora's implementation of KDE.
Comment 56 Rex Dieter 2018-02-16 14:35:21 EST
I don't think that's a fair characterization.

However, such comments have no place in bugzilla.

Given the history and status of this bug, I'm closing it: WONTFIX

If anyone is ever able/willing to step up to address it, we can re-open.
Comment 57 JNoake 2018-02-16 16:52:18 EST
> 
> Just to be clear, the flaw is not a flaw of KDE, but rather Fedora's
> implementation of KDE.

So. in interests of trying to help those in need using KDE on Fedora, do you have at least a suggestion for a viable alternative that *does* work?
What is KDE's recommended GUI package manager?
Comment 58 JNoake 2018-02-16 16:59:50 EST
(In reply to Kevin Kofler from comment #54)
> 
> Dnfdragora is the recommended package management tool nowadays. It is
> toolkit-agnostic, using libyui, which can use Qt, GTK+ and ncurses under the
> hood.
> 
> There is also Plasma Discover, which is more like GNOME Software
> (application-centric, using AppStream), but which may also fit your needs.
> 
> Both are installed by default on the current versions of the Fedora KDE Spin.


Thanks - missed this before my last post.

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