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