Bug 435630
| 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> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | 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-21 00:36:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 235705 | ||
|
Description
Jeremy Katz
2008-03-02 19:00:00 UTC
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. So I click a tab and now I have to wait for 20 megs of data to be transferred? That makes me feel better... 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. (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. > 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. 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. |