GNOME Bugzilla – Bug 731708
Please add metainfo files for the various Evince plugins
Last modified: 2014-06-23 06:36:15 UTC
Evince ships lots of plugins which we'd like to show in gnome-software. Here's an introduction to what metainfo is all about and what we're trying to achieve: https://blogs.gnome.org/hughsie/2014/06/11/application-addons-in-gnome-software/
Patch will come through 30 mins.
Created attachment 278532 [details] [review] add appdata files We also want to add AppData file
Created attachment 278533 [details] [review] backends: add metainfo files for the backends
The appdata file is already covered by bug 708760. Apart from using a non-free metadata licence, I question the need to have the backends all have their own metadata info. The backends ship with evince, are usually packaged all in the same package as evince, and not intended to be choose-and-match. Also, adding these files duplicates the info in the existing evince backend xml files that evince uses to find its backends, so e.g. new mime types would need to be added in both... what's the purpose of these files? IMHO the link in comment 0 doesn't explain why evince should add them.
(In reply to comment #4) > The backends ship with evince, are > usually packaged all in the same package as evince, and not intended to be > choose-and-match. If it's not designed to be able to install and remove backends, then I guess metainfo files are redundant.
(In reply to comment #5) > (In reply to comment #4) > > The backends ship with evince, are > > usually packaged all in the same package as evince, and not intended to be > > choose-and-match. > > If it's not designed to be able to install and remove backends, then I guess > metainfo files are redundant. [brain@X1Carbon evince]$ sudo dnf erase evince-djvu Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: evince-djvu x86_64 3.12.1-3.fc21 @System 40 k Transaction Summary ================================================================================ Remove 1 Package Installed size: 40 k [brain@X1Carbon evince]$ sudo dnf info evince-dvi Available Packages Name : evince-dvi Arch : x86_64 Epoch : 0 Version : 3.12.1 Release : 3.fc21 Size : 88 k Repo : koji Summary : Evince backend for dvi files URL : http://projects.gnome.org/evince/ License : GPLv2+ and GPLv3+ and LGPLv2+ and MIT and Afmparse Description : This package contains a backend to let evince display dvi files. So it can be used separate I think.
$ rpm -ql evince-libs /usr/lib64/evince /usr/lib64/evince/4 /usr/lib64/evince/4/backends /usr/lib64/evince/4/backends/comicsdocument.evince-backend /usr/lib64/evince/4/backends/libcomicsdocument.so /usr/lib64/evince/4/backends/libpdfdocument.so /usr/lib64/evince/4/backends/libpsdocument.so /usr/lib64/evince/4/backends/libtiffdocument.so /usr/lib64/evince/4/backends/libxpsdocument.so /usr/lib64/evince/4/backends/pdfdocument.evince-backend /usr/lib64/evince/4/backends/psdocument.evince-backend /usr/lib64/evince/4/backends/tiffdocument.evince-backend /usr/lib64/evince/4/backends/xpsdocument.evince-backend /usr/lib64/girepository-1.0/EvinceDocument-3.0.typelib /usr/lib64/girepository-1.0/EvinceView-3.0.typelib /usr/lib64/libevdocument3.so.4 /usr/lib64/libevdocument3.so.4.0.0 /usr/lib64/libevview3.so.3 /usr/lib64/libevview3.so.3.0.0 we can split this in other packages thought.
I wonder why the fedora packaging separates djvu but not pdf, ps, xps, tiff, cba ?
(In reply to comment #8) > I wonder why the fedora packaging separates djvu but not pdf, ps, xps, tiff, > cba ? that's happens from start packaging in fedora. < 2.32 Anyway we can split it out.
(In reply to comment #4) > The appdata file is already covered by bug 708760. ok. I'm obsoleting patch. > Apart from using a non-free metadata licence, I question the need to have the > backends all have their own metadata info. The backends ship with evince, are > usually packaged all in the same package as evince, and not intended to be > choose-and-match. Also, adding these files duplicates the info in the existing > evince backend xml files that evince uses to find its backends, so e.g. new > mime types would need to be added in both... what's the purpose of these > files? IMHO the link in comment 0 doesn't explain why evince should add them. what you means under non-free metadata license? CC0-1.0 is free. http://spdx.org/licenses/CC0-1.0
CC* is not free, at least as I understand it (it's a lot of incomprehensible legalese, after all, so I could have missed something). But as far as I can see, it has no requirement to provide the corresponding source in the form preferred for modification.
(In reply to comment #8) > I wonder why the fedora packaging separates djvu but not pdf, ps, xps, tiff, > cba ? I think it's to do with the deps that the different backends drag onto the LiveCDs. (In reply to comment #11) > CC* is not free, at least as I understand it Both Fedora and Debian consider it free. I'm talking to some legal teams at the moment to allow GPL (and other code licenses) appdata/metainfo files, although there is some more work to do. If you want to include these under a GPL license then it's highly likely in the future they'll be used at least in Fedora.
(In reply to comment #12) > (In reply to comment #8) > > I wonder why the fedora packaging separates djvu but not pdf, ps, xps, tiff, > > cba ? > > I think it's to do with the deps that the different backends drag onto the > LiveCDs. > > (In reply to comment #11) > > CC* is not free, at least as I understand it > > Both Fedora and Debian consider it free. I'm talking to some legal teams at the > moment to allow GPL (and other code licenses) appdata/metainfo files, although > there is some more work to do. If you want to include these under a GPL license > then it's highly likely in the future they'll be used at least in Fedora. Yes. Christian, if other looks good for you - if you really want to change license I could change it and commit to the repo.
I don't think <updatecontact> should point to something that's not controlled by evince devs, ie bugzilla. Am I right in assuming that the appdata files are taken from the build, not from the tarball? In that case, those should all be nodist_appstream_DATA instead of appstream_DATA. The problem with the data duplication (mime types list) isn't solved by that, but let's hear what the other evince devs think. KaL ?
(In reply to comment #14) > I don't think <updatecontact> should point to something that's not controlled > by evince devs, ie bugzilla. Yes, usually it's the upstream maintainer. > Am I right in assuming that the appdata files are taken from the build, not > from the tarball? In that case, those should all be nodist_appstream_DATA > instead of appstream_DATA. No, they are taken from the installed system, i.e. they are installed to /usr/share/appdata when the package is installed. This allows the metadata to be used on distros that do not ship AppStream metadata yet and also means the files get included in the distro packages. > The problem with the data duplication (mime types list) isn't solved by that, > but let's hear what the other evince devs think. KaL ? The mime-type lists are parsed from the .desktop file at build time, but in the case where the backends are split out, I think the .desktop mimetypes will not be accurate.
(In reply to comment #15) > (In reply to comment #14) > > I don't think <updatecontact> should point to something that's not controlled > > by evince devs, ie bugzilla. > > Yes, usually it's the upstream maintainer. Definitely not what the current patch does :-) > > Am I right in assuming that the appdata files are taken from the build, not > > from the tarball? In that case, those should all be nodist_appstream_DATA > > instead of appstream_DATA. > > No, they are taken from the installed system, i.e. they are installed to > /usr/share/appdata when the package is installed. This allows the metadata to > be used on distros that do not ship AppStream metadata yet and also means the > files get included in the distro packages. Ok, this means we need to make out main app data file installable from the tarball as well, it's currently marked as nodist. > > The problem with the data duplication (mime types list) isn't solved by that, > > but let's hear what the other evince devs think. KaL ? > > The mime-type lists are parsed from the .desktop file at build time, but in the > case where the backends are split out, I think the .desktop mimetypes will not > be accurate. It's unfortunate that we need to duplicate the MIME type list. As Christian said, evince builtin backends are not meant to be distributed separately (although it's perfectly possible), what happens with distros that split the backends differently? Shouldn't they provide their own app data files for the backends they package independently? like third-party backends would do?
(In reply to comment #16) > Ok, this means we need to make out main app data file installable from the > tarball as well, it's currently marked as nodist. Nodist simply makes the generated file not be in the tarball. The source is still present (EXTRA_DIST) and will build and install the .appdata.xml at build time.
It would be awesome if we could get the metainfo files upstream before 3.13.3 (three days time!) and then we can get some testing of the plugin installing and removal. We've also added code to libappstream-builder that automatically ignores the meainfo if the plugin is already installed in the main package along with the application. Thanks!
I've pushed a different patch that generates the xml files from the Makefiles directly to be able to reuse the MIME types lists from configure.ac.
(In reply to comment #19) > I've pushed a different patch that generates the xml files from the Makefiles > directly to be able to reuse the MIME types lists from configure.ac. +APPDATA_SUMMARY=Adds support for reading DjVu Documents documents ^^^^^^^^^ +APPDATA_NAME=DjVu Documents Documents ^^^^^^^^^ dupes +[type: gettext/ini]backend/comics/evince-comicsdocument.metainfo.xml.in ^^^^^^^^^^^^^^^^^^^ why we need this? I think that's wrong. Otherwise looks good.
(In reply to comment #20) > (In reply to comment #19) > > I've pushed a different patch that generates the xml files from the Makefiles > > directly to be able to reuse the MIME types lists from configure.ac. > > +APPDATA_SUMMARY=Adds support for reading DjVu Documents documents > ^^^^^^^^^ > +APPDATA_NAME=DjVu Documents Documents > ^^^^^^^^^ > dupes > Oops, thanks, I'll fix that. > > +[type: gettext/ini]backend/comics/evince-comicsdocument.metainfo.xml.in > ^^^^^^^^^^^^^^^^^^^ > why we need this? I think that's wrong. You are right, I copy pasted from backeds file that are ini files, will fix it too. > > Otherwise looks good. Thanks!