----- Original Message -----
Am 17.07.2017 um 12:16 schrieb Bastien Nocera:
It's like you didn't listen to the arguments when this feature was implemented in Fedora years ago, and continue not to. You're wrong, and the fact that you keep insisting you're not is frankly intellectual dishonesty.
If you really believe you're correct, try to kill your X server in the middle of an upgrade... Or simply re-read the tons of examples in the old threads.
guess what happens when "dnf "i s running within a screen session and "KillUserProcesses=no" is set other then the silly default - the upgrade continues without any issue
Offline upgrades predate this systemd feature by a number of years. You also completely dismiss the amount of work that might be needed to make it use screen, whether screen can survive all the changes underneath it.
so fix the update tools to work implicit that way instead burry the wrong handling with "oh we apply updates due reboot"
"Fixing the update tools" doesn't fix the breakage handled by applications when you change files from underneath them. Again, read the original threads to get a complete picture.
And when you take it all into account, the fix looks something like Flatpak, with atomic upgrades, and parallel installation.
On Monday, 17 July 2017 at 13:15, Bastien Nocera wrote: [...]
"Fixing the update tools" doesn't fix the breakage handled by applications when you change files from underneath them. Again, read the original threads to get a complete picture.
And when you take it all into account, the fix looks something like Flatpak, with atomic upgrades, and parallel installation.
How does Flatpak handle application updates and downgrades when the application introduces incompatible changes to user data format between versions and supports data migration only one-way? Or parallel installations in the same situation?
My guess is it doesn't.
Regards, Dominik
Hi,
Dominik 'Rathann' Mierzejewski kirjoitti 18.07.2017 klo 14:28:
On Monday, 17 July 2017 at 13:15, Bastien Nocera wrote: [...] How does Flatpak handle application updates and downgrades when the application introduces incompatible changes to user data format between versions and supports data migration only one-way? Or parallel installations in the same situation?
My guess is it doesn't.
Regards, Dominik
My guess, too, would be that it does not address this situation. Some of the burden would be on application developers to try to keep their data formats stable. With suitable namespaces it would be possible to have configuration of the various versions stored separately, but I do not actually know if flatpak has implemented any handling for this case.
- Joonas
On 18 July 2017 at 16:36, Joonas Sarajärvi muep@iki.fi wrote:
My guess, too, would be that it does not address this situation.
Sure, flatpak doesn't do this, because it can't. If the application author wants to rev the schema of the config, then they have to handle to migration -- and it's unlikely they want to handle a reverse migration in the downgrade case. The current best case is we don't overwrite the config, but write the config with a different namespace, so if you downgrade you get the config pre-migration, rather than the config also downgraded (as the old version wouldn't know anything about the new schema version).
Richard
-
Bastien Nocera -
Dominik 'Rathann' Mierzejewski -
Joonas Sarajärvi -
Richard Hughes