Bug 1098735

Fwiw, on f20, installing regular updates *mostly* works, just get an occasional packagekitd crasher though, bug #1057843

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).

Shouldn't this be filed against PackageKit (i.e. the main package from which PackageKit-hawkey is built)?

oops, right.  reassigning->PackageKit

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.

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? :-(

(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

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.

> 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?

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).

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).

(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

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.

(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.

(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

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.

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.

(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.

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.

I'll retest the updating part specifically, and report back.

Another question: Is it possible to install new packages by searching for them by name, or does that also not work?

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.

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.

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?

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/

Update on matters.

Talks with hughsie, we found a proper path to get a solution, and we will be working on that ASAP.

21 is done, cleaning blocker process metadata.

Fix under upstream review: https://github.com/hughsie/PackageKit/pull/20

*** Bug 1178146 has been marked as a duplicate of this bug. ***

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.

> 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.

@Richard Hughes

Can you please merge the patch and fix packagekit hif backend?
there isn't only gnome

Has anything been done to fix this bug?  I've tried several things mentioned on several sites, but nothing has worked yet.

(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

*** Bug 1215851 has been marked as a duplicate of this bug. ***

Heh. Thanks for the great work as always!  I don't think we can say often enough how much it is appreciated.

(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.

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...

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.

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.

marking as FutureFeature to avoid autoclose

I thought the idea was to switch to muon?

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)

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.

muon as distributed by kde.org in plasma releases... includes only muon discover and muon updater

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.

*** Bug 1297708 has been marked as a duplicate of this bug. ***

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 ?

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

*** Bug 1357986 has been marked as a duplicate of this bug. ***

Still able to reproduce in Fedora release 25.

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!

> 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.

(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.

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.

> 
> 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?

(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.