GNOME Bugzilla – Bug 734645
Fix handling of games that have a -data package
Last modified: 2018-01-24 16:52:11 UTC
Many games in Fedora (and probably other distros too) have a -data package containing the game data files, and a regular package containing the actual executable / libraries. This is done so you could patch code bugs in the executable without forcing the users and mirrors to download the heavy -data package.
The -data package is useless without the main executable, but in many cases the -data package doesn't "depend" on the main package.
There are two ways in which we handle this wrong:
1) Size estimation is off. So for 0ad for example we show it's 3.2MB, while it requires a -data package that is a 546MB download and 1.3GB on disk.
2) When removing the game from Software, the -data package will not be removed. This can either be solved with some special-casing in Software (easy) or convincing the maintainers to "do the right thing" (probably not easy).
*** Bug 746741 has been marked as a duplicate of this bug. ***
Solving problem one is at first seemingly trivial, just calculate the size of the package and all it's dependencies, but then how do we differentiate between all the obvious trivial dependencies like X or glib or whatever, and a dependency that is like xonotic-data is to xonotic, or libreoffice-core is to libreoffice-writer. Is there some kind of term for this, or existing guidelines we use to distinguish between these types of dependencies?
One possible solution is calculating the install size if the user were to install the package right now, accounting for all installed dependencies, and dependencies that need to be installed, but how long would this take to calculate?
yum does that pretty well already, it shows the download size and the installed size when the prompt whether the user really wants to install it is shown (counting also dependency updates, rpm diffs and so on). Yum also shows the progress of the download and other useful information.
What you really need is a machine-readable format of that data and convert it into your UI elements. Whether it's yum or dnf doesn't matter to regular users.
As a (happy) user of gnome-software, I find the lack of feedback about installation size and progress an occasional source of surprises.
(In reply to David Gumberg from comment #2)
> Solving problem one is at first seemingly trivial, just calculate the size
> of the package and all it's dependencies, but then how do we differentiate
> between all the obvious trivial dependencies like X or glib or whatever, and
> a dependency that is like xonotic-data is to xonotic, or libreoffice-core is
> to libreoffice-writer. Is there some kind of term for this, or existing
> guidelines we use to distinguish between these types of dependencies?
I think this distinction is almost irrelevant for the user. When I see a package I want to install, I mostly care about how many megabytes this will cost, on my system, with the current set of packages. The distinction between general dependencies and package specific dependencies is very much beyond the scope of a graphical installer. For example, on a gnome system, if I try to install a kde binary, I might need to pull in a few hundred megs of generic deps, but what matters for my decision whether to install or not is the total download/install size.
OTOH, gnome-software is explicitly about applications, and not about packages. So the fact that the manager split out -data should be hidden completely imho. Only package+dependencies are relevant for the user.
> One possible solution is calculating the install size if the user were to
> install the package right now, accounting for all installed dependencies,
> and dependencies that need to be installed, but how long would this take to
Yeah, that would be perfect. It probably takes a second or two to calculate this. Maybe it could be done asynchronously, and displayed when ready. This way this information would be available to the user after she is finished reading the description.
>It probably takes a second or two to calculate this
If we have all the metadata handy, but it also requires getting a lock on the rpmdb so it would have to block on anything else that's happening. That's the #1 ason I've not implemented a SimulatedInstall->Size refine action. When you're switching tabs even 2 seconds feel really slow.
Also reported in
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-software/issues/14.