The app-text/evince ebuild lists gnome-base/gvfs as an RDEPEND. This appears to be incorrect. I have tried removing gnome-base/gvfs (by overriding with an empty ebuild in an overlay), afterwards evince was able to rebuild fine, and appeared function.
I believe it uses /usr/libexec/gvfsd-metadata at runtime for some features, fwiw.
For more background: gvfs is a package that goes hand in hand with glib (its GIO part) to provide extensions for it. gvfs is primarily known for implementing various different remote filesystem supports for GIO to use (that ANY glib using app can make use of it), but it also implements extension points for trash virtual filesystem, some metadata handling, recent files, and so on. You shouldn't consider gvfs a GNOME thing, but very useful to have for any glib/gtk app. For evince case we'd need to dig deeper on what it provides, it's a bit hard to figure out easily due to the gio extension points stuff via gvfs - there's no direct linkage going on there, evince would be using GIO API and then that via extension points talks with gvfs over dbus to provide some features, and if not there, some things would just silently not work. Everyone's mileage might vary if they need those lost small features or not, but we are also in the business of having things just work, not in avoiding tiny deps that benefit many useful things for all gtk apps. Frankly, this bug makes me wonder why we don't PDEPEND on gvfs by default in dev-libs/glib.
(In reply to Mart Raudsepp from comment #2) > For more background: gvfs is a package that goes hand in hand with glib (its > GIO part) to provide extensions for it. gvfs is primarily known for > implementing various different remote filesystem supports for GIO to use > (that ANY glib using app can make use of it), but it also implements > extension points for trash virtual filesystem, some metadata handling, > recent files, and so on. > > You shouldn't consider gvfs a GNOME thing, but very useful to have for any > glib/gtk app. > For evince case we'd need to dig deeper on what it provides, it's a bit hard > to figure out easily due to the gio extension points stuff via gvfs - > there's no direct linkage going on there, evince would be using GIO API and > then that via extension points talks with gvfs over dbus to provide some > features, and if not there, some things would just silently not work. > Everyone's mileage might vary if they need those lost small features or not, > but we are also in the business of having things just work, not in avoiding > tiny deps that benefit many useful things for all gtk apps. > Frankly, this bug makes me wonder why we don't PDEPEND on gvfs by default in > dev-libs/glib. I don't really have any experience with the internals of profiles, but wouldn't selecting this via a desktop profile be a way to achieve this? I am under the impression that if you do *not* select a desktop profile (which I have not), it's up to you to ensure your desktop apps "just work". If this is possible (and not unreasonable) it would give the best of both worlds: people's systems just work, and people have the choice of what to install.
