Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

----- 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.

F27 System Wide Change: Graphical Applications as Flatpaks

[Dominik 'Rathann' Mierzejewski]

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
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

F27 System Wide Change: Graphical Applications as Flatpaks

[Joonas Sarajärvi]

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

F27 System Wide Change: Graphical Applications as Flatpaks

[Richard Hughes]

On 18 July 2017 at 16:36, Joonas Sarajärvi <muep(a)iki.fi&gt; 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