#47972: LaTeXML: texlive-related improvements --------------------------+---------------------------- Reporter: mojca@… | Owner: bruce.miller@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: LaTeXML | --------------------------+---------------------------- Comment (by mojca@…): At the moment there are two variants (`texlive` and `mactex`), none of which is enabled by default, so currently the situation is "worse" (user needs to actively do something to get any style file installed at all). Replying to [comment:7 bruce.miller@…]:
Maybe some background would help to understand a slightly peculiar situation.
Thanks for explanation.
Given all your thought provoking comments, I'm inclined to think that perhaps the following approach would be good. Have the `+mactex` variant as it is, but if `+mactex` is not used (would that be a "default" variant?), proceed as: * have no additional texlive dependencies, but issue a note or warning about the desirability of installing it if it isn't present. * go ahead and install the style files where the texlive PortGroup would expect them if it were there. * gently attempt to run `mktexlsr`, if it is available. (I assume that post-activate would still be run when the ''user'' installs LaTeXML, even when it's been prepared by a buildbot?) Unfortunately, this slightly changes behaviour depending on context, which seems frowned upon. Is that a fatal flaw?
Yes, post-activate is run even if the package comes from the buildbot. And no, it's not a fatal flaw. I don't see any problem at all.
This would then allow the user to install any texlive set or subset they want, before or after installing LaTeXML. Probably installing a texlive package after LaTeXML would automatically invoke `mktexlsr`?
Yes, it would. If LaTeXML wouldn't depend on LaTeX, then: * either user already has `mktexlsr`, so `post-activate` would run it, * or user didn't install the package with `mktexlsr` before installing LaTeXML, so the command wouldn't be run, but as soon as the package containing `mktexlsr` gets installed, the command `mktexlsr` is being run so it would work properly and as desired in any case. My suggestion would be to keep providing a non-conflicting `+mactex` variant that would install the style files under `TEXMFLOCAL` (independent of whether it also installs files under `$prefix/share/texmf`). I'm unable to decide what users want. Personally I have TeX from MacPorts installed, but only because some packages depend on it, and even then I tried to make sure to only install the minimal possible set. My default TeX comes from MacTeX, so even if I would install LaTeXML with `+texlive`, running LateXML in command line would probably call latex from MacTeX. Independent of what else gets done and implemented, I would suggest to install the two style files under `$prefix/share/texmf` by default. Then we would have the following options: * don't provide a separate `+texlive` option; just ask the users to install `texlive-something` manually * don't provide a separate `+texlive` option and force a dependency on `texlive-something` (unless the user picked `+mactex`; then just install the style files to both locations anyway, just don't require a dependency on texlive) * provide a separate `+texlive` option, just don't make it a default * provide a separate `+texlive` option and make it default (I would actually suggest to also install the style files to `/usr/local/texlive/texmf-local` by default if that wasn't somewhat "against the general guidelines" of how MacPorts are supposed to work.) I believe the final decision about the best strategy should depend on maintainer. My main wish is to try to avoid a dependency on the complete texlive installation (and to minimize the dependencies on the buildbot to the bare minimum if that doesn't require extra effort or dirty hacks). The rest is up to you. -- Ticket URL: <https://trac.macports.org/ticket/47972#comment:8> MacPorts <https://www.macports.org/> Ports system for OS X