On Tue, 2017-07-18 at 15:51 -0400, Matthew Miller wrote:
> * ability to mix and match versions and streams
Hi,
my personal knowledge of Flatpak is close to zero at the moment, thus
this is more a newbie reply.
My understanding of Flatpak, and the main advantage of it from my point
of view, is to get most recent versions of applications to the users as
soon as possible, without a need to reinstall whole system due to (up
or down) dependencies, which sounds pretty cool. One can run software
for the most recent Fedora on years old Fedoras (not only Fedora, but
let's make it simple here), everything is just a matter of using proper
runtime and bundle libraries which are required for the application.
The downside is disk usage, but I do not want to reopen this here, it
had been widely discussed in the "F27 System Wide Change: Graphical
Applications as Flatpaks" thread. I suppose you plan to have several
runtimes, to avoid having installed Fedora, then two other Fedoras as
runtimes, when one would like to test two different versions on a
running system, where the same application (and/or its possibly
incorrect dependencies) is installed as well.
That thread opened also one question about versions and user data. If
you use an application which changed its internal data format between
two versions, but you still want to run both versions (like to be able
to test differences and eventually catch regressions), then you cannot
share user data between them, can you? The application certainly
supports switch from old format to the new, not vice versa (how would
old software knew about the new format?). How is this dealt with in
Flatpak world? Should each application tell Flatpak to use different
XDG directories, in which case the user data will not be shared between
applications?
What about DConf settings. While at least I only add new GSettings
keys, once some version removes a key it cannot be shared with the
older versions (GSettings aborts the application on missing
schemas/keys), or it'll be a mess, on the first look.
What about critical path packages? Are those meant to be part of the
runtime? Or should each of the applications bundle them? Imagine a real
life example, gnome-todo, gnome-contacts, gnome-calendar and Evolution.
They all use evolution-data-server and it's evolution-data-server,
which takes care of storing locally cached data. The 3.26.x has changed
background data storage for contacts and calendars. If I want to be
sure that each of them uses correct data server, then either I bundle
it to each of them, or I use a runtime which contains it. Due to the
data format change I cannot use shared home, even though they all are
meant to share it, to avoid redefinition of the accounts for each
application (passwords/OAuth2 tokens through keyring could be probably
shared).
What about the connection to GNOME Online Accounts? To have consistent
behavior, bundle it as well? Or it'll be part of some runtime? Could
those GOA accounts be shared between different versions? There's
similar problem with internal data format like with the data server.
I've been told that debugging of Flatpak applications is no fun. I
didn't try it myself, thus I cannot tell for sure, but for me as a
consumer the use of Flatpak to deliver software early also means that
I'd be able to debug regressions easily, from getting debug logs turned
on with environment variables, down to getting useful backtraces of
crashed or running applications.
That is, if I want to deliver an application to the users early, no
matter what distribution they use, I'm meant to use proper runtime,
bundle as much as possible, thus the code can actually run anywhere and
consistently, and use specific XDG directories per each Flatpak. That
pretty much sounds like a work for the upstream, not for the Fedora,
because using Fedora runtime means getting tight to Fedora only. Or
not? My natural choice would be to use GNOME runtime instead (though
I've no idea about its usability on other distributions than it is
built on).
Am I understanding this wrong, both from the Fedora point of view and
from the upstream point of view?
Thanks and bye,
Milan
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
