Graphical Distribution Upgrades

Stephen Gallagher sgallagh at redhat.com
Mon Apr 6 20:56:31 UTC 2015


Broken from the "Summary of Reddit thread".

Fedora's lack of a graphical major-version updater comes up 
constantly. I think it's probably time to start brainstorming how to 
solve it, with a stated intention of having things work for upgrading 
Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having 
Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 
22's stable lifecycle to support this).

So to brainstorm, I'll start with a list (in no particular order) of 
things I think we want as goals (not necessary technical goals but 
user experience goals) and then go into a few known technical 
enhancements that need to be accomplished to get there. (Note: many of 
the experience goals may already be possible with some combination of 
GNOME Software and/or fedup, but they are included for completeness).

Much discussion welcome!

p.s. I am not a member of the Workstation WG, but I am a highly-
interested party.



== User Experience Goals ==
 * The user must be informed that a major-version upgrade is available 
soon[1] after it is released in a manner that is consistent with the 
integrated operation of the system.

 * The user must have the option to "snooze" this notification for a 
sensible amount of time (or permanently) to avoid nag.

 * The mechanism must be capable of informing the user of how much 
disk space will be required to perform the update prior to their 
initiating one.

 * The upgrade mechanism must *not* download any files other than 
metadata prior to a user request for upgrading.

 * The upgrade mechanism, once requested, must download all packages 
to be upgraded locally before starting (to avoid network issues in the 
middle of the upgrade process).

 * The distribution upgrade mechanism *must* take place in a dedicated 
upgrade environment with no other services running.

 * The updater must be capable of first updating *itself* to the 
latest stable version prior to attempting an upgrade. This *may* also 
require updating all packages on the local system to their latest 
versions, if needed.

 * The resultant state of the machine after an upgrade should be 
equivalent[1] to a freshly-installed system of the new version, 
configured the same way as the previous version.

 * Once the system has entered the dedicated environment, the updater 
should[2] complete successfully or else make no changes to the 
installed system, when only Fedora repositories are enabled.

 * The update notification should be configurable to support upgrades 
to Alpha and Beta releases, if desired.

== Non-goals ==
 * It is not a requirement to be able to downgrade from a successful 
distribution upgrade.



== Technical implementation thoughts ==
 * For Fedora Workstation, the obvious graphical front-end should be 
GNOME Software

 * ... However, the low-level should be implemented by PackageKit so 
that other DEs can implement their own solutions.

 * The fedup tool already provides a non-graphical implementation of 
the dedicated upgrade environment (as well as some odds-and-ends for 
managing changes that aren't handled by simple package upgrade 
scripts). This logic should be moved to PackageKit and maintained 
there, with fedup becoming a CLI client implementation of it.

 * The Fedora infrastructure would need to add new metadata to 
describe releases (also supporting Alpha and Beta releases) that the 
upgrade mechanisms may query for. Mirror-manager is probably a good 
place for this.

 * From a user perspective, GNOME software should provide AppStream 
metadata for a Fedora N+1 package, which would have special properties 
of enabling the distribution-upgrade. (Modeled somewhat after OSX 
upgrades which are done by "purchasing" the new version in their OSX 
app store)

 * When the user receives a notification for a distribution upgrade, 
clicking on that notification should bring them to the upgrade entry 
in GNOME Software (or other tool as appropriate to other spins).


[1] Definition malleable.
[2] I hate the word "should", but I don't want *every* edge case as a 
bug here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20150406/e8e2146f/attachment.sig>


More information about the desktop mailing list