F23 System Wide Change: DNF System Upgrades

[Kevin Fenzi]

= Proposed System Wide Change: DNF System Upgrades = 

https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades

Change owner(s):

* Will Woods (fedup author)
* Zbigniew Jędrzejewski-Szmek (systemd developer)
* Radek Holy (DNF developer)

== Detailed Description ==

While fedup worked well in many circumstances, there were a lot of
problems resulting from using upgrade.img. This has caused nasty,
hard-to-debug blocker bugs for every release since it was introduced.

It turns out that upgrade.img was relying on some undocumented,
unsupported systemd behavior. After F22 this was discussed on the
systemd-devel mailing list, and the conclusion was that fedup's boot
behavior is broken by design, and systemd can't (and won't) continue to
support it.

systemd already supports a simpler, more reliable method for performing
Offline System Updates; the systemd team suggests using that to perform
system upgrades.

Most of the remaining problems with fedup were caused by the fact that
it was separate from the system packaging tools, and therefore had
slight (and confusing) differences from the normal package update
mechanisms.

Therefore, we propose that system upgrades should be handled by the
system packaging tools, using systemd's Offline System Updates facility.

dnf-plugin-fedup is a proof-of-concept implementation; we propose to
integrate support for this into DNF itself.

== Scope ==

Proposal owners:

Make DNF able to send progress output to Plymouth (basically done; see
dnf #281 and #313)

Modify Offline System Updates spec as needed to support major system
upgrades (in progress, see this systemd-devel thread)

Support Offline System Updates in DNF (dnf-plugin-fedup does this, but
it could be integrated into DNF itself)

Add plugin to dnf-plugins-core or dnf

Write man pages and other documentation

Obsolete and retire fedup

Other developers:

Fix any conflicts with packagekit-offline-update.service
In the unlikely event that some kind of offline system migration is
necessary (like UsrMove), it should be handled the same way as UsrMove
- i.e. by a dracut script that runs the first time the new system boots after the upgrade. 

Release engineering:
Drop upgrade.img from image builds
Policies and guidelines:
FedUp, Upgrading, and other documentation will need changes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150729/68ddaef6/attachment.sig>
-------------- next part --------------
_______________________________________________
devel-announce mailing list
devel-announce at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce