----- Original Message ----- > 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. Sorry, it was clearer in my head. The "no" applies to library APIs, the "yes" applies to D-Bus "remote" APIs. > > 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 will be the case for any host-side feature, especially the ones that rely on online services (gnome-online-accounts is probably another), or the ones that rely on hardware-related bug fixes. That's par for the course, and that will probably mean more backporting and stable releases. > 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). On mobile, this would be split up more, so the calendar backend would live in the Calendar app, the Notes backend in the Notes app, etc. This leaves the sign-on on the host side. But they can do that because they have blessed front-ends which we don't in GNOME or Fedora. _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
