On Wed, May 10, 2023 at 8:06 AM Milan Crha <mc...@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
