On Sat, 2014-01-25 at 23:26 +0100, Tomasz Torcz wrote: > On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote: > > On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote: > > > > > > > > If there is a directory that contains update and non-update related file > > > > changes, that's a problem. If there's segmentation, then this can be done. > > > > > > Note that this situation is perfectly handled by Offline Updates. > > > After reboot, there aren't collateral changes to filesystem, only upgrade-related > > > ones. So if there's a need for revert, the previous state is clearly defined. > > > > Sorry, but this is simply not true. > > > > > > The ONLY way to do that is if you do not care at all about user's data > > and simply accept that a rollback will also remove user data. > > > > The reason is simple: lot's of software *changes* data as part of its > > normal functioning, including and often in rollback-incompatible ways. > > What user data? There is no user data touched/created during offline upgrade. No, but you may have to use the system somewhat before you can find out there was a problem with the upgrade, and at *that* point, your user data may now be tied to the new versions of system apps, as Simo describes. So, it goes like this: * Do an offline update that includes Foo v2.0 * Boot the updated system, run Foo, it migrates its configuration to some new scheme * Realize there was something wrong with the update, roll it back * Run Foo again, find it doesn't work because it's been migrated to the new config scheme which the old version of Foo doesn't work with -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
