Hi, On Fri, 2018-02-16 at 04:50 -0500, Bastien Nocera wrote: > No, the Flatpak and host are separate. I'm guessing that you're > worried about mismatches between evolution-data-server and its > clients. Heh, you just say 'no' and then change it to 'yes'. Some applications do depend on system services, regardless what they are built against. > There's really no other way to make this work than to work towards a > stable, and versioned API. It's not about API by any means. The (D-Bus and code) API can be stable, but the underlying code can change. I know that software like GNOME Calendar and GNOME Contacts and others use mentioned evolution- data-server (eds) and they compile against some version, but then use the host version of the D-Bus services. It's fine as long as you do not care of functionality. It happens often that some bug is noticed on the client side (being it GNOME Calendar, GNOME Contacts, Evolution,...), but the actual fix for it lands in the eds, like into the builtin backend. This fix doesn't change API, no soname version bump needed, no D-Bus service version number increased). That means that the Flatpak version can be built against eds which has the bug fixed, but whether it's truly fixed depends on the host system. That's odd. Adding eds into Flatpak is not correct from the point of sharing the same data between various applications and the system (GNOME Shell) itself (unless some portals of Flatpak or what that idea to catch on this was named). > > If not, and the plan is to use Flathub exclusively, will Fedora > > push the applications there instead of the upstream/package > > maintainer in case where the upstream/package maintainer is not in > > favor of github, the place where Flathub is hosted? > > The upstream maintainer doesn't have to use Flathub, and GitHub, but > they'd have to replicate the setup. Which is one of the reasons why > people use Flathub to build and distribute those rather than doing it > themselves separately. Yes, not talking that the upstream might tell the users how to add they Flatpak repository to their system. It didn't answer my original question though. > Flatpak cannot guarantee host dependencies either. That's both a > feature and a bug, making it harder to build applications that rely > on specific versions of host services, outside the sandbox, and > easier to upgrade applications without pulling new dependencies at > the host level. I agree. Flatpak cannot be an answer to everything, not for such complicated tasks like shared data between the host system and various either Flatpak or native applications. Simple standalone applications work fine with Flatpak, just not those complicated. At least not right now. My main concern is about Fedora. As I said, maybe it had been already answered elsewhere, I only didn't catch the answer. Fedora should not use some 3rd-party "repository" to deliver applications to users, it should have control on the applications being delivered in the distribution (reproducible builds, anyone?), thus provide its own Flatpak repository, in case it's really going to use Flatpak to deliver content to their users. Whether such Flatpak repository should be usable by any Fedora version onward or only being used by single Fedora version is another question. Just my opinion. Bye, Milan _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
