#1 Don't Require gvfs for Flatpak builds
Opened a month ago by feborges. Modified a month ago
rpms/ feborges/libosinfo drop-gvfs-for-rpm2flatpak  into  master

Don't Require gvfs for Flatpak builds
Felipe Borges • a month ago  
file modified
+4

@@ -22,7 +22,11 @@ 

  Requires: hwdata

  Requires: osinfo-db >= 20181011-1

  Requires: osinfo-db-tools

+ %if 0%{?flatpak}

+ Requires: gvfs-client

+ %else

  Requires: gvfs

+ %endif

  

  %description

  libosinfo is a library that allows virtualization provisioning tools to

Otherwise we would have to pull gvfs into the "gnome-boxes"
flatpak module/container because libosinfo pulls it in.

The same fix has been merged into gedit, see
https://src.fedoraproject.org/rpms/gedit/pull-request/3

See https://docs.fedoraproject.org/en-US/flatpak/tutorial/

I forgot mentioning in the commit message that the "flatpak" macro is provided by the "flatpak-rpm-macros" package.

So, according to what I could understand ... apps should be relying on gvfs-client when dealing with flatpak in order to avoid pulling gvfs into each app.
Based on that ... I'd add an else and explicitly requires gvfs-client (which is currently part of the runtime).

Another thing to have in mind is that detecting an OS by its tree URL will simply not work if gvfs is not installed in the system ...

rebased onto 4e677cd

a month ago

I rebased the commit to explicitly Require gvfs-client for Flatpak builds and gvfs otherwise.

What's the problem with pulling 'gvfs' into flatpak - it is needed by libosinfo n order for http(s) URIs to actually work, so by not pulling it in we're simply breaking things, which I think it not really desirable.

If the problem is that gvfs has too many dependancies, then the obvious solution would be to modularize the gvfs RPM to a greater extent.

For example gvfs should be a empty RPM, which just has a bunch of dependencies of gvfs-protocol-http, gvfs-protocol-ftp, gvfs-protocol-$BLAH.

That way apps which want full gvfs support continue to work as today. Apps which only need a specific protocol(s) can just depend on the appropriate gvfs-protcol-$BLAH sub-RPMs

This is to avoid pulling gvfs in every single flatpak bundle.

For context: these Flatpaks generated from RPMs are to be used in Fedora Silverblue. That ships a GNOME desktop with a very minimal set of applications, but that includes Nautilus (the file browser), for instance, that will pull gvfs in the compose.

That doesn't really answer the question. What is the actual problem with pulling in gvfs ?

It contains daemons and helpers that are supposed to run in the host (out of the container).

Anyway, they could be pulled in the module and container, we don't need the duplication. Feel free to close the PR then.

In other words, "pulling" gvfs in the modulemd won't use it. It is just a build requirement because it is in the spec file. The gvfs daemons running will be still the host ones.