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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
