[aur-general] When to use optdepends

Markus Schaaf mschaaf at elaboris.de
Thu May 14 17:53:42 UTC 2020

Am 12.05.20 um 17:53 schrieb Eli Schwartz via aur-general:

> I'd generally expect an optdepends for something which the program
> has a built-in ability to use simply by installing the optdepends.

I'm sorry, but since you came up with the (IMO too clever by half)
suggestion to add optdepends, I expected a somewhat more elaborate
answer, considering the details of *that* package. The problem I have
is this:

The package defines a couple of custom commands for compiling (la)tex
to PDF and whatnot. (This is IMO a negligibility, because the main
purpose of that editor plugin is to provide tools for *editing* latex
files, not command suggestions for whatever task the author came up
with.) One such command sequence is:

rubber [...] --pdf "$filename"
gvfs-open "$shortname.pdf"

Now, rubber is like make, but for latex. And it's of the same
complexity. Please have a glance at the man page. What it does and
what programs it calls depends largely on the input (and
configuration). Like make it may potentially call a lot of different
programs. Even before considering which of these to include in
optdepends, I would need to know them. I don't use rubber, and by
cursory look I haven't found that information. The rubber package
itself does not optdepend on anything. Like the make package. Am I
supposed to find out? As the maintainer of an editor plugin? You could
depend on texlive, but texlive doesn't contain everything. One surely
needs more to compile something other than latex Hello-world.

This was the first line. The second is even better. gvfs-open calls
the preferred PDF-viewer. Should I decide which? Or suggest all I can

Don't get me wrong. I'm not opposed to your suggestion to include some
helpful optdepends. It's just not *that* easy. Arch is not Debian. I
haven't looked, but Debian probably has a virtual package for
PDF-viewer and a list of candidates. Ubuntu has flavours where someone
decided which of these candidates it is. Even if Arch had flavours, an
AUR package would not.

This was only the first command. There are more. :-)


More information about the aur-general mailing list