On Mon, May 15, 2023 at 1:51 AM Milan Crha <mcrha@xxxxxxxxxx> wrote:
On Wed, 2023-05-10 at 09:30 -0400, Owen Taylor wrote:
> Does that sound workable? Are there better ways we could do it?
Hi,
if I recall correctly, using the custom D-Bus prefix is there to match
application's D-Bus prefix defined for the flatpak, thus:
a) the services run independently from the system, inside the sandbox;
b) they can be started without any additional effort on the Flatpak
configuration side (because the services share the app's D-Bus
prefix).
I briefly grepped the evolution-data-server sources and it seems that
most of the places in the .c files can be changed in runtime, but there
are places where the things can break, like the `evolution-data-
server.pc` file or the D-Bus .service files, which both reference the
D-Bus name from the compile time and those .service files are also
named by the service (otherwise there's a runtime warning in the
journal about the file not matching the service name). Those might not
be show stoppers, I guess.
The idea is that we'd substitute the name and contents of the service files at container creation time. The .pc file is tricker, since it is build time. Those variables aren't used much.
I found two examples:
- libfolks uses it when setting up a private bus for test cases - shouldn't matter
- You use it in to fix bus names in flatpak-evolution-wrapper.sh - those could just be hardcoded since the bus name will be always the same for the Evolution Flatpak
By the way, when people install Evolution flatpak, they have
preinstalled evolution-ews inside it. How will they install it after
this change?
The idea is that the container.yaml can list any number of packages to be installed in the Flatpak. The first one is the "main" one, but that only means that the name/version of the Flatpak come from it by default. Adding evolution-ews as an additional package will work fine.
- Owen
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
