Bug 962097

Hum, yeah, this isn't right. ;) 

As a workaround: 

yum install zathura-pdf-poppler

and it should work, but you shouldn't have to do so. :(

OK, thanks! That works :)

AFAICT the choice is to have zathura depend on all its plugins, which defeats the plugin philosophy, or the statu quo, which lets the end-user choose which plugin(s) to install.
I'm rather happy with the current setup, so I'm closing this (NOTABUG).
Please feel free to reopen if you do not agree.

PS: Thank you Kevin. :)

I agree with François and adding that to %description (done already) was the way to go.

Would it be possible to change the error you get with no plugins installed?

Something more like "You must install at least one plugin of ..." or something?

Just a thought.

It should be rather easy, except maybe for the upstreaming of said patch.
I'll work on it, thanks for the suggestion :)

(In reply to François Cami from comment #3)

Is there a chance for a one round for Fedora 18 - with a note about plugins and a Zathura-plugins-all subpackage, all by 0.2.3.?

http://lists.fedoraproject.org/pipermail/users/2013-May/435829.html

(In reply to Kevin Fenzi from comment #5)
> Would it be possible to change the error you get with no plugins installed?
> 
> Something more like "You must install at least one plugin of ..." or
> something?
> 
> Just a thought.

Maybe something like Amarok or Rhythymbox when you try to open an mp3 file: "This format isn't supported, do you want to look any plugin?" or sort of option/message; I think this how it should be done: giving still the option to the user; but without the headache.

Re: comment 3

> AFAICT the choice is to have zathura depend on all its plugins,
> which defeats the plugin philosophy,

This is a misunderstanding of the plug-in concept, IMO. The primary purpose of a plug-in interface is _extensibility_ and decoupling of a main program from its extensions. Making every plug-in optional to reduce install footprint (or such) is a very questionable goal. A good plug-in method makes it possible to disable individual plug-ins at run-time.

For the users of upstream Zathura in source from this also means they don't need to spend time on building plugins they don't want.

However, a distributor such as Fedora should know better. As such, the "zathura" packaging leaves much to be desired.

It would have been a better choice to make "zathura" a meta-package for easy installation, which pulls in "zathura-core" (or zathura-base) and the most important plugins (or even all plugins that are available).

D(In reply to Michael Schwendt from comment #9)
> Re: comment 3
> 
> > AFAICT the choice is to have zathura depend on all its plugins,
> > which defeats the plugin philosophy,
> 
> This is a misunderstanding of the plug-in concept, IMO. The primary purpose
> of a plug-in interface is _extensibility_ and decoupling of a main program
> from its extensions. Making every plug-in optional to reduce install
> footprint (or such) is a very questionable goal.

I cannot agree with it

> A good plug-in method makes
> it possible to disable individual plug-ins at run-time.
> 
because there is no point having a plug-in installed if the plug-in is disabled.

> For the users of upstream Zathura in source from this also means they don't
> need to spend time on building plugins they don't want.
> 
> However, a distributor such as Fedora should know better. As such, the
> "zathura" packaging leaves much to be desired.
>
I wouldn't like to start argue who knows better.

> It would have been a better choice to make "zathura" a meta-package for easy
> installation, which pulls in "zathura-core" (or zathura-base) and the most
> important plugins (or even all plugins that are available).

Did you want to say a comps group?

I can see the point that package `foo' should deliver all the bits coming from `foo' sources. It's a valid policy. This should be standardized to provide consistent user experience.

FYI:
* Zathura is not a Fedora project, e.g. neither I nor Petr S. are upstream for Zathura.
* We can request changes to upstream sources, with the caveat that upstream may or may not be inclined to make them.
* We also accept patches and will forward them to upstream.

We also made our point clear - we will not make Zathura depend on all its plugins. I agree that the application should display a warning when launched without any though.

With that out of the door, I added yesterday - before getting flamed, I should say - a zathura-plugins-all packages that depends on all the plugins, and changed the description to:

"
Zathura is a highly customizable and functional document viewer.
It provides a minimalistic and space saving interface as well as
an easy usage that mainly focuses on keyboard interaction.

Zathura requires plugins to support document formats.
For instance:
* zathura-pdf-poppler to open PDF files,
* zathura-ps to open PostScript files,
* zathura-djvu to open DjVu files.
All of these are available as separate packages in Fedora.
A zathura-plugins-all package is available should you want
to install all available plugins.
"

This is in rawhide - I will push to f19+f18 in a few days.

Granted, this will only change what rpm/yum & friends display about Zathura.
Yet this is consistent with what other well-known packages do - see nagios, and nagios-plugins-all, for instance.

> because there is no point having a plug-in installed
> if the plug-in is disabled.

That depends on what the plug-in does. For the user it can make sense to disable plug-ins temporarily, e.g. if they want to choose between multiple alternative ones, or if one causes side-effects, or if it has changed to the worse temporarily. Having to uninstall/reinstall an RPM package is no substitute for that.


> I wouldn't like to start argue who knows better.

Distributors typically aim at making it easy for users to get a working system. If users need to figure out what tiny bits are missing, that's neither helpful nor convenient. On the contrary, if the packages are prepared in a flexible way, users may figure out how to install a stripped-down set of packages if they really want that. That ought not be the default. We don't do a "minimal install" with the default spin either.


Latest koji build of Zathura still advertises being "A lightweight PDF viewer". It also does that in GNOME Shell's default Software Installer. That needs to be fixed before closing this bug.


A new zathura-plugins-all package has been introduced. It would be listed/sorted somewhere between zathura-pdf-poppler and zathura-pdf, whereas a different packaging would appear like:

  zathura : Highly customizable and functional document viewer
  zathura-base : Just the graphical frontend without any plug-ins
  zathura-devel : ...
  zathura-mupdf : ...
  zathura-pdf-poppler : ...


Would that zathura-plugins-all package work as intended? For example, how would Zathura handle two different plug-ins for PDF support? (e.g. poppler and mupdf)
Does one take precedence over the other? Or is the user forced to uninstall either one?


> I can see the point that package `foo' should deliver all
> the bits coming from `foo' sources. It's a valid policy.

Is that documented anywhere? With such a policy, e.g. Audacious would not do much without its plug-ins, which reside in a separate package and are built from a different src.rpm.

For Audacious we even had to kill all separate .desktop files for the individual file formats in individual (sub-)packages, because GNOME Shell Default Applications couldn't handle the multiple files that referred to Audacious. What happens if multiple Zathura plugin .desktop files use "Name=Zathura" and advertise the same MIME type?


> Did you want to say a comps group?

No. My opinion is that a "yum install zathura" should install something useful, not a crippled frontend that cannot handle any documents at all.


As a compromise, if a warning dialog could be added, I would consider that as helpful. Agreed?

> For the user it can make sense to disable plug-ins temporarily
> e.g. if they want to choose between multiple alternative ones

Agreed, but this is on upstream side, not Fedora's.
I suggest working with them directly.

> Latest koji build of Zathura still advertises being "A lightweight PDF viewer". 

Oy, I had not updated the summary. Good catch, thank you. Fixed:
http://koji.fedoraproject.org/koji/buildinfo?buildID=422375

> how would Zathura handle two different plug-ins for PDF support? (e.g. poppler and mupdf)

I have no idea. I should mention that zathura-mupdf is not packaged yet because it has less features than the poppler plugin.

> As a compromise, if a warning dialog could be added, I would consider that as helpful. 

Zathura currently outputs to STDERR "error: unknown file type" if there is no plugin to handle the file you are trying to open.
However, the plugin-system is handled in document.c while the window system is handled in zathura.c - and there is no built-in way to pass the error from document.c to zathura.c. So while creating a new window to display an error message is easy, it does not look good, and trying to display the error in the main window is tricky though. 
I am going to add a way to forward the error from document.c to zathura.c but I am loath to patch what we ship until upstream accepts my patch.

(In reply to François Cami from comment #13)
> > how would Zathura handle two different plug-ins for PDF support? (e.g. poppler and mupdf)
> 
> I have no idea. I should mention that zathura-mupdf is not packaged yet
> because it has less features than the poppler plugin.

Those two plugins conflict.

Anyhow, I dare to say zathura targets a different audience (e.g. me) than Gnome and forcing Gnome packaging practices here is somewhat off.  When I install a piece of software, I expect just that -- not a bunch of plugins I won't ever use and can't easily remove from my system while keeping the original software I wanted.  Installing xorg-x11-server-Xorg, fortunately, also doesn't pull in xorg-x11-*.  Even though it doesn't really work without any drivers installed.

Until there's some official Fedora global policy on how to handle those things, I'm against making 'zathura' some kind of metapackage.

What I do agree with is showing a message in zathura window (in addition to stderr) when a) there are no plugins installed at all, and b) a plugin required to handle the file cannot be found.  I believe this is upstreamable, however it will, according to François, require somewhat deep changes in the code first.  Until this is possible, I'd say stderr messages are just fine.

Created attachment 753920 [details]
display a warning when a file cannot be opened

Minimally invasive way to display a warning when a file cannot be opened.
Note that this is less than optimal due to the inability to detect why the file cannot be opened: either due to a missing plugin or because it does not exist.

Patch sent to upstream.

Patch accepted by upstream:
https://git.pwmt.org/?p=zathura.git;a=commit;h=cf96d52790bc8d05a9e556e33af0b6fec1a4cb0e

and fixed in rawhide:
http://koji.fedoraproject.org/koji/buildinfo?buildID=422468

I'll backport to f18/f19 in a few days.

Great, François!

girara-0.1.6-2.fc19,zathura-0.2.3-4.fc19,zathura-ps-0.2.2-2.fc19,zathura-pdf-poppler-0.2.3-2.fc19,zathura-djvu-0.2.3-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/girara-0.1.6-2.fc19,zathura-0.2.3-4.fc19,zathura-ps-0.2.2-2.fc19,zathura-pdf-poppler-0.2.3-2.fc19,zathura-djvu-0.2.3-2.fc19

(In reply to François Cami from comment #17)
…
> I'll backport to f18/f19 in a few days.

zathura-0.2.2-2.fc18
http://koji.fedoraproject.org/koji/buildinfo?buildID=422951

OK, thanks Fran.

Our (Petr and I) pleasure. Please leave karma on bodhi as soon as the packages are available in updates-testing:

For f18:
https://admin.fedoraproject.org/updates/zathura-0.2.2-2.fc18

For f19:
https://admin.fedoraproject.org/updates/girara-0.1.6-2.fc19,zathura-0.2.3-4.fc19,zathura-ps-0.2.2-2.fc19,zathura-pdf-poppler-0.2.3-2.fc19,zathura-djvu-0.2.3-2.fc19

Package girara-0.1.6-2.fc19, zathura-0.2.3-4.fc19, zathura-ps-0.2.2-2.fc19, zathura-pdf-poppler-0.2.3-2.fc19, zathura-djvu-0.2.3-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing girara-0.1.6-2.fc19 zathura-0.2.3-4.fc19 zathura-ps-0.2.2-2.fc19 zathura-pdf-poppler-0.2.3-2.fc19 zathura-djvu-0.2.3-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-9651/girara-0.1.6-2.fc19,zathura-0.2.3-4.fc19,zathura-ps-0.2.2-2.fc19,zathura-pdf-poppler-0.2.3-2.fc19,zathura-djvu-0.2.3-2.fc19
then log in and leave karma (feedback).

girara-0.1.6-2.fc19, zathura-0.2.3-4.fc19, zathura-ps-0.2.2-2.fc19, zathura-pdf-poppler-0.2.3-2.fc19, zathura-djvu-0.2.3-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.