Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Lots of less than useful information shown in the UI|
|Product:||[Fedora] Fedora||Reporter:||Jeremy Katz <katzj>|
|Component:||gnome-packagekit||Assignee:||Robin Norwood <robin.norwood>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-04-20 20:36:48 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Jeremy Katz 2008-03-02 14:00:00 EST
The UI of pk-application shows a lot more information than an end-user really cares about including file lists, raw dependency lists and required by. In addition to adding a lot of clutter, this also means that users are always having to download the (large) file lists when this really should be a rare operation
Comment 1 Richard Hughes 2008-03-03 16:13:14 EST
You only need to download the file lists if you actually click the files tab; the file list should only be refreshed when it's actually needed. In the future, they'll be a simple application installer without all this extra junk, something like gnome-app-install. We'll need more PkExtra metadata and quicker group results (or caching) for this to be a reality, although it's something I can start to work on in a few days/weeks.
Comment 2 Jeremy Katz 2008-03-03 22:35:16 EST
So I click a tab and now I have to wait for 20 megs of data to be transferred? That makes me feel better...
Comment 3 Robin Norwood 2008-03-04 09:40:08 EST
Would it be better to not give the user access to the data? The wait is the same whether you ask for the data from PK or from yum. If we need to, we can turn off this feature for the yum backend until it's fast enough - this is one of the things the incremental metadata work is supposed to fix, isn't it? Also, you can cancel the file list by clicking somewhere else if it takes too long, so the user isn't stuck, even the the user experience is sucky.
Comment 4 Jeremy Katz 2008-03-04 10:12:02 EST
(In reply to comment #3) > Would it be better to not give the user access to the data? The wait is the > same whether you ask for the data from PK or from yum. It's hardly _useful_ data. What are you going to do, browse through the package lists and the lists of files they provide to find what you're looking for? Similarly with the dependencies/whatrequires tabs > If we need to, we can > turn off this feature for the yum backend until it's fast enough - this is one > of the things the incremental metadata work is supposed to fix, isn't it? What incremental metadata? There's no way to do incremental downloading of file lists really. The goal is to not download them whenever you can possibly avoid it. That's why they were separated out.
Comment 5 Robin Norwood 2008-03-04 10:22:34 EST
> What incremental metadata? There's no way to do incremental downloading of file > lists really. The goal is to not download them whenever you can possibly avoid > it. That's why they were separated out. My understanding was that skvidal + co were working on making all of the metadata changes 'incremental' so that instead of downloading big tarballs of data that were mostly the same each time, the user gets the first tarball, then can download changesets for the data. I may have completely misunderstood something I heard in passing, though, and this may not actually be happening. > It's hardly _useful_ data. What are you going to do, browse through the package > lists and the lists of files they provide to find what you're looking for? > Similarly with the dependencies/whatrequires tabs This is a good point. It's kindof neat to be able to see this data, but it probably doesn't belong front and center in a general purpose package installer for desktop users.
Comment 6 Richard Hughes 2008-04-20 20:36:48 EDT
This belongs in gpk-application IMO. There'll be an easy-application installer soon, and gpk-application with be the power tool, rather than an easy-software installer. If you disagree, please discuss on the mailing list. Thanks.