GNOME Bugzilla – Bug 719304
UI for any packaging preferences has been lost with gnome-packagekit
Last modified: 2014-04-07 16:08:43 UTC
The replacement of gpk with Software by default (as in Fedora 20) has an unfortunate consequence: there's no GUI for any packaging-related settings or preferences any more. The settings are still there in dconf, but AFAICS there's no UI for any of them - even ones which probably ought to have UI - in Software itself or in control-center. For instance, you can't enable or disable a repository anywhere. You can't turn off background update downloads (say, you have a tight bandwidth cap). You can't configure whether or not to download updates over a mobile broadband connection. Etc etc... Software itself or control-center should grow settings for whichever of these we think ought to be exposed as GUI choices, I guess.
Yeah, we decided that repository configuration was not in scope for now. The other settings you mention do affect the gsd updates plugin in F20, but that is on going away post-F20. The replacement code in the gnome-software-service does not look at these settings. It implements the following logic: https://bug709121.bugzilla-attachments.gnome.org/attachment.cgi?id=256126
There are people using cellular-based internet with very low caps (1 or 2GB per month). There are people using extremely slow shared connections (especially in developing countries). I'm really not sure if you can have a one size fits all background update downloading policy. Android doesn't, for instance. But this might move outside the scope of bugzilla. If configuring repositories is not in scope for Software then what exactly *is* it in scope for? It's clearly a capability we've had for a long time and still ought to have.
oh, and by 'cellular-based internet' I don't mean things GNOME can actually tell are a 'mobile internet' connection, I'm talking about 'home' internet connections that use cellular links (commonly used in remote areas where the only other alternatives are POTS or satellite). The PC would be hooked up with wifi or an ethernet cable. But such services generally have very tough caps.
(In reply to comment #2) > There are people using cellular-based internet with very low caps (1 or 2GB per > month). There are people using extremely slow shared connections (especially in > developing countries). I'm really not sure if you can have a one size fits all > background update downloading policy. Android doesn't, for instance. But this > might move outside the scope of bugzilla. It is quite possible that some tweaks for the update policy will come back eventually. Just to clear that up: We are not downloading when we are on what the old code considered a 'mobile or expense' network. > If configuring repositories is not in scope for Software then what exactly *is* > it in scope for? It's clearly a capability we've had for a long time and still > ought to have. Whats the problem ? Notice the 'for now' qualification in my statement. This tool is about installing available applications, not about fiddling with the plumbing of where those applications come from. So we're focusing on building out the main functionality of gnome-software first, before adding the decorative accessories. Nobody is taking that capability away from you if you are into editing .repos files. The existing gpk-prefs dialog for configuring repositories is really not a big loss. But you are right, that it is best to continue this kind of discussion outside of bugzill.
GNOME Software 3.12 can add and remove repos, but no change any policy on for what connection type we should download updates. IIRC, we only download on wired/wireless and we show a warning page on mobile which the user can ignore and refresh and update manually. I think that's probably about right for software now and matches the latest designs.
it *might* make sense to have a simple on/off for background update downloading somewhere, as there are cases that cannot be well covered by heuristics. For example, a tablet running GNOME that's sharing a phone's data plan via wifi.