| Summary: | app-text/atril doesn't ensure metadata support (gvfs at runtime) or notify about it | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mart Raudsepp <leio> |
| Component: | Current packages | Assignee: | OzTiram <oz.tiram> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | leio, oz.tiram |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/36295 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Mart Raudsepp
2017-03-14 20:35:01 UTC
Curious about a couple points: 1) Does this feature require a rebuild to enable, or is it handled by a dependency (libraries, pipes, or otherwise) at runtime which may or may not be fulfilled, removed, changed, etc. at a later date + properly detected when available. 2) best I can tell - nothing in the ebuilds for atril seems to mention metadata or gvfs (and it's not in the upstream docs either) nor does a quick glance at [ configure.ac ] seem to explicitly mention it. Is this feature provided by gio or does it come from somewhere else? (anyone with relevant knowledge could probably answer this) 3) It's possible that other users (I haven't personally, but also people other than myself) have never used evince, so saying "just like evince" as the only information about the feature you're describing is likely vague enough that more information will help track down this feature / behavior / bug for testing or modification of dependencies, etc. What's exactly is this evince-like metadata / gvfs feature? (In reply to Mart Raudsepp from comment #0) > atril seems to require gvfs for metadata support, just like evince, but > doesn't express it in any way. Might be good to look into that and depend on > it with some IUSE=+metadata or unconditionally or at least elog/whatever > something Where do you see that Atril requires gvfs? As far as I can tell, all the metadata bits are using glib. Based on a lazy search of github's source https://github.com/mate-desktop/atril/search?q=gvfs&type=Code&utf8=%E2%9C%93, there are two fixmes suggesting using gvfs, but no other references to gvfs as far as a preliminary look revealed. This was what other people ended up with for evince. So maybe that logic was wrong and GIO is able to save metadata without /usr/libexec/gvfsd-metadata backing it too (not sure and hard to test getting rid of gvfs on a GNOME system; maybe I can hide the metadata daemon from it...). I'll have to recheck the logic.. g_file_info_set_attribute_string docs say "Sets the attribute to contain the given attr_value, if possible". I thought it to not possible without gvfsd-metadata, but this information might be outdated or never fully correct. I believe if it turns out to not be possible, you just lose saving bookmarks and titles cache or something - what that in turn means for the user visibly - I'm not fully sure. The existing references are to set a key in gsettings I believe, to indicate if old metadata pre-gio has been migrated over to gio, but the key name contains "migrated-to-gvfs", not gio, suggesting gvfs is needed too. I'll look deeper later on to get this sorted properly for both atril and evince. Is this still an issue with recent versions of atril? Yes, I don't see anything having changed. It still has a metadata thing which calls g_file_info_set_attribute_string, which won't have anywhere to store anything if gvfs isn't there. Further investigation into other means of metadata storage it might have these days might still be applicable too. But I don't see anyone using a gtk app reasonably refusing to have gvfs anyways. I mean, there will be some that are minimizing dep without realizing they'll be losing a bunch of features randomly, but in general gvfs goes closely with glib and gtk to support stuff considered basic these days, e.g. remote filesystems support; trash handling; ability to browse iOS and Android filesystems, etc etc. Thanks for clarifying. Indeed other distributions add gvfs as a runtime depency This is required for example for adding bookmarks for PDFs. See for example here: https://github.com/mate-desktop/atril/issues/559 I will add a use flag for this. Don't really see a need for a USE flag, personally, instead of just unconditionally RDEPENDing on it, but up to you. I have been close to just depending on it in glib or gtk myself, but figured maybe someone really uses only a single gtk app that doesn't gain anything from gvfs - but that isn't the case here, it gives required functionality and by not having it there means that functionality is just silently broken. A user probably can add bookmarks and things, but they won't be there later. evince I've also just made unconditionally RDEPEND on gvfs for this. |