[aur-general] When to use optdepends

[Eli Schwartz]

On 5/14/20 1:53 PM, Markus Schaaf wrote:
> 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
> find?
> 
> 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. :-)

I'm no expert on the plugin, I haven't used it and I don't do latex...
but the name of the plugin implies it's intended to be used for a
specific type of command. If it's just a... general command runner? with
a couple of default commands that aren't particularly suited to
universal use, then maybe I've misunderstood and it doesn't really merit
an optdepends.

I assumed it would be something like e.g. a hardcoded menu entry to run
some standard and usually-useful command that most people using it would
want to run, with maybe the ability to customize it for exotic needs.
Since it's apparently a lot more nebulous than that, I guess I was
wrong. Anything that needs to have its command be configured before you
can reasonably expect to use it, seems like the user would need to also
figure out their own set of dependent software too. There's no out of
the box experience.

OK then -- I retract my suggestion.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20200514/3073be6c/attachment.sig>