On Wed, May 10, 2023 at 8:06 AM Milan Crha <mcrha@xxxxxxxxxx> wrote:
On Wed, 2023-05-10 at 11:54 +0100, Aoife Moloney wrote:
> Additionally a couple of packages (evolution-data-services and
> tracker-miners) are set up so they can be
> built with an application-specific D-Bus prefix. Evolution has:
>
> buildopts:
> rpms:
> macros: |
> %_eds_dbus_services_prefix org.gnome.Evolution
>
> This will need to be redone so that evolution-data-services doesn't
> need recompilation
> and the prefixing can be done by changing configuration files at
> container build time.
Hi,
I cannot speak for the tracker-miners, but in case of the Evolution, it
runs in its own sandbox, separated from the host system, with bundled
evolution-data-server (eds) services, thus when the user installs the
Flatpak version, he/she gets the expected Evolution and eds versions,
independent of what the host system has installed. Advantage: the user
gets all fixes, not only client-side (Evolution) fixes. It's important,
from my point of view.
We'll still have an evolution-data-server that runs inside the sandbox and has prefixed names, it will just have to be done a different way. My best current idea is that for the (single) Flatpak build, the evolution-data-services would have
-DDBUS_SERVICES_PREFIX=com.example.FlatpakApp
Then we'd change things (preferably upstream) so instead of building DBUS_SERVICES_PREFIX into the source code,
com.example.FlatpakApp.org.gnome.evolution.dataserver.AddressBook10.service
would have:
Exec=/app/libexec/evolution-addressbook-factory --dbus-services-prefix=com.example.FlatpakApp
Then container.yaml would have something like:
dbus-service-substitute=com.example.FlatpakApp:org.gnome.evolution
And that would do that substitution in the names and contents of any service files when building the container. Does that sound workable? Are there better ways we could do it?
> In many cases, this should consist of just a few minor changes to
> container.yaml.
Do you mean the `evolution.yaml` is gone with this change and the
dependencies are taken directly from the .spec file? The eds dependency
is a problem here, as you noted, not talking that not everything from
the .spec file requires a rebuild for the flatpak (most dependencies
are part of the runtime).
Yeah, evolution.yaml is gone with the change. Any dependency that is not part of the runtime will have to have been rebuilt in the f39-app target, or the container build will fail. Then we'll have some convenience at the fedpkg level to make that not too painful. ('fedpkg flatpak-build' will check that things seem ok before starting the build, and there will be 'fedpkg flatpak-build-rpms --all-missing' to rebuild the missing dependencies.)
- 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
