[MacPorts] #47972: LaTeXML: texlive-related improvements
MacPorts
noreply at macports.org
Sat Jun 6 09:43:30 PDT 2015
#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
More information about the macports-tickets
mailing list