Bug 435630

Summary: Lots of less than useful information shown in the UI
Product: [Fedora] Fedora Reporter: Jeremy Katz <katzj>
Component: gnome-packagekitAssignee: Robin Norwood <robin.norwood>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: richard
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-20 20:36:48 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235705    

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.