On Wed, 2017-07-19 at 08:49 +0200, Milan Crha wrote: > On Tue, 2017-07-18 at 15:51 -0400, Matthew Miller wrote: > > * ability to mix and match versions and streams
Hi Milan - Thanks for all the questions! Some of these are better brought up on a Flatpak or GNOME mailing list and you'd get better answers, but I'll answer to the best of my ability here. I also think that Evolution is pretty much a worse case scenario for putting into a Flatpak - it stores huge amounts of data, shares that data with the rest of the GNOME desktop, and has all sorts of complicated ties built up over many years of shared history. It's great to think about how it will work in a Flatpak, but we shouldn't get depressed if it seems hard - not all applications are that hard! > 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. I'm not entirely sure I follow the question, but yes, if you want to run F27 applications, you'd have the F27 runtime installed as well. It's not going to be tiny, but it will be a lot smaller than a full install of F27. > 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? Well, it's largely up to the application author to evolve their data and settings in a way that is backwards compatible. I think a lot of application authors do that anyways, because they want to be working on new versions of their application while still maintaining a stable branch. If an application has to break storage formats, it probably is better to do it as a one-time-migration leaving the old data in place. (This is obviously not practical if the data is 20GB of email!) Flatpak bases where it stores the data of the application off of the application ID. You can change the application ID and get a clean slate - but then you don't have migration. (Nightly development builds in particular may use a different application ID so that they can be tried out "risk-free") > 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. GSettings schemas are considered part of the application, and are shipped in the Flatpak. What would be shared is the (schema-less) DConf storage. If the DConf storage mismatches the schemas, the schemas will be used to provide default values. There are certainly still cases where the application could change settings in a way that would cause old application versions to have problems. Application authors generally need to to take care not to change the meaning of existing settings keys, only add new ones. > 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). evolution-data-server is definitely a problem for the Flatpak model - the entire idea of Flatpak is that different applications and the operating system can be updated separately. If Evolution, GNOME Contacts, and the operating system (GNOME Shell) are bound together by a complicated, evolving D-Bus service, then that simply isn't possible. It would be possible to have contacts and calendar events as "portals" - as services provided by the operating system to applications. But then that would have to be tightly version controlled, there would have to be a security model, and there would have to be some plan that would work when the desktop doesn't include EDS (what if you are running on KDE?) Would the flatpak runtime include a simple implementation? Generally, it's least surprising if data is scoped to the application, and that's the model we plan for. But I understand it's not how Evolution works currently. I'd encourage you to discuss this within the GNOME community. > 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 don't think bundling GNOME Online Accounts makes sense - it appears like part of the desktop to the user. In the unsandboxed case, you can just access the D-Bus service from your application. We'd need an "accounts portal" of some sort for the sandboxed case, figuring out the security model and user interaction, since arbitrary applications should definitely not be able to get your credentials from GOA. Again you'd need a fallback implementation - which could simply be "no I don't have any account information". > 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. We definitely don't want debugging Flatpak applications to be no fun! Some of it is a matter of maturity of tooling, some of it is a matter of experience... hopefully it's getting better all the time. With Flatpaks built with flatpak-builder, the debug information is available as an "extension" that you can install with the application. The same will have to be done for Flatpaks built with Fedora content, though we haven't fully figured out the details there. > 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). It will be entirely possible to run Fedora Flatpaks on other distributions - to say "if you want to try out Evolution 3.26 - install the Fedora flatpak". A user that installs the Fedora flatpak will see the Fedora stream of security updates - you'd need to be responsible for that yourself if you shipped an application built directly from source. Owen _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
