LaTeXML: texlive-related improvements

[mojca (Mojca Miklavec)]

I would like to suggest the following improvements:

• try to figure out the smallest subset of texlive to make latexml +texlive functional (possibly defining different depends_build and depends_run)
• calling system /usr/texbin/mktexlsr might be problematic (the files from MacTeX might be owned by root)
• one might want to disable calling mktexlsr during make install
• I can imagine that depends_build might not even need to depend on anything from TeX Live even with +texlive variant: all the package needs to do is to copy two files to the appropriate place (or am I wrong?).

See also #46896.

[brucemiller (bruce miller)]

Replying to mojca@…:

I would like to suggest the following improvements:

• try to figure out the smallest subset of texlive to make latexml +texlive functional (possibly defining different depends_build and depends_run)

Aha! I hadn't realized that MacPorts had adopted the many-small-packages approach. LaTeXML doesn't actually *require* any tex, but will work best with at least a minimal amount. You'd likely want latex, mktexlsr, dvips, and can use dvipng, dvisvgm. Can use other packages if they're installed, but the user can install whatever they expect to use.

I would guess "texlive-latex" is sufficient.

• calling system /usr/texbin/mktexlsr might be problematic (the files from MacTeX might be owned by root)

That's true. Does it fail or warn in such circumstances? What will happen is that MacTeX's latex won't be able to find LaTeXML's style files, unless the user re-runs mktexlsr with appropriate permissions.

• one might want to disable calling mktexlsr during make install

Could be; Is it better to run from "make" or from "post-activate"? OR, does the PortGroup texlive automatically arrange for mktexlsr?

• I can imagine that depends_build might not even need to depend on anything from TeX Live even with +texlive variant: all the package needs to do is to copy two files to the appropriate place (or am I wrong?).

Other than mktexlsr (so the files are findable by TeX), that's right.

See also #46896.

[mojca (Mojca Miklavec)]

Replying to bruce.miller@…:

I hadn't realized that MacPorts had adopted the many-small-packages approach. LaTeXML doesn't actually *require* any tex, but will work best with at least a minimal amount. You'd likely want latex, mktexlsr, dvips, and can use dvipng, dvisvgm. Can use other packages if they're installed, but the user can install whatever they expect to use.

I would guess "texlive-latex" is sufficient.

I would try to go for texlive-basic if that's feasible. At least mktexlsr is part of that package.

I added Dan to CC. Dan, in case you are reading this: would it be possible (feasible) to put mktexlsr in some even more "standalone" package? It's just a shell script that requires texmf.cnf, hardly anything more advanced than that.

• calling system /usr/texbin/mktexlsr might be problematic (the files from MacTeX might be owned by root)

That's true. Does it fail or warn in such circumstances?

I assume it just prints warnings, but I need to check.

What will happen is that MacTeX's latex won't be able to find LaTeXML's style files, unless the user re-runs mktexlsr with appropriate permissions.

Maybe the port should skip running mktexlsr and ask the user to do that.

• one might want to disable calling mktexlsr during make install

Could be; Is it better to run from "make" or from "post-activate"?

It's not sufficient to run it from make (not to say useless: because the file isn't in place at the time when make is called – at that time it's still in destroot). The command is needed both in post-activate as well as in post-deactivate because that's the step when you add or remove the file to/from the TeX tree

Actually, the post-deactivate step is also missing now (not that it's really relevant though; it just means that TeX will think the file is there).

OR, does the PortGroup texlive automatically arrange for mktexlsr?

No, it doesn't.

• I can imagine that depends_build might not even need to depend on anything from TeX Live even with +texlive variant: all the package needs to do is to copy two files to the appropriate place (or am I wrong?).

Other than mktexlsr (so the files are findable by TeX), that's right.

mktexlsr during make is useless as already explained above. At the time when latexml's scripts call mktexlsr the relevant files are at some obscure location in destroot. You previously needed kpsewhich in the Portfile, but we also got rid of that one.

(I don't know what happens if you ask for texlive.mktexlsr in a post-activate step on the buildbot. Maybe we should test and file a bug report if it fails ;)

[brucemiller (bruce miller)]

Replying to mojca@…:

Replying to bruce.miller@…:

I would guess "texlive-latex" is sufficient.

I would try to go for texlive-basic if that's feasible. At least mktexlsr is part of that package.

I think texlive-basic is too low; you'd really want latex or not bother installing tex at all.

I added Dan to CC. Dan, in case you are reading this: would it be possible (feasible) to put mktexlsr in some even more "standalone" package? It's just a shell script that requires texmf.cnf, hardly anything more advanced than that.

Not really useful: without some form of tex to look for files, you really don't need mktexlsr to index them!

• one might want to disable calling mktexlsr during make install

Could be; Is it better to run from "make" or from "post-activate"?

It's not sufficient to run it from make (not to say useless: because the file isn't in place at the time when make is called – at that time it's still in destroot). The command is needed both in post-activate as well as in post-deactivate because that's the step when you add or remove the file to/from the TeX tree

DOH! Yes, of course; the installation is staged (same for linux rpms).

The mktexlsr in the Makefile is coded to be innocent, if noisy, so it really shouldn't cause a problem. I'm adding another switch to disable mktexlsr to be used in staged installation, like MacPorts & rpm. But it won't make it into CPAN until the next release. Is this problem maybe ignorable for now?

(I don't know what happens if you ask for texlive.mktexlsr in a post-activate step on the buildbot. Maybe we should test and file a bug report if it fails ;)

Is texlive.mktexlsr intended to be a safe way replacement for system "mktexlsr"? If so, it seems the right thing do use.

[mojca (Mojca Miklavec)]

Replying to bruce.miller@…:

I think texlive-basic is too low; you'd really want latex or not bother installing tex at all.

OK. But for the buildbot I still see no reason to bother with installing LaTeX first. (I would actually try if one could install the file without any tex being present at all. That would speed up the build on the buildbot a lot.)

The mktexlsr in the Makefile is coded to be innocent, if noisy, so it really shouldn't cause a problem.

I agree.

I'm adding another switch to disable mktexlsr to be used in staged installation, like MacPorts & rpm. But it won't make it into CPAN until the next release. Is this problem maybe ignorable for now?

Sure.

(I don't know what happens if you ask for texlive.mktexlsr in a post-activate step on the buildbot. Maybe we should test and file a bug report if it fails ;)

Is texlive.mktexlsr intended to be a safe way replacement for system "mktexlsr"? If so, it seems the right thing do use.

Yes. Here's what it does:

# update texmf file path databases (ls-R)
#
# This should be run in the post-activate/deactivate hooks of any port
# that installs texmf files. It updates the kpathsea database using
# mktexlsr (formerly texhash), as well as ConTeXt's cache.
proc texlive.mktexlsr {} {
    global prefix

    # Run mktexlsr. If that's not available, something's wrong.
    system "${prefix}/bin/mktexlsr"

    # If mtxrun is available (i.e. ConTeXt is installed), update its
    # cache too. If it's not installed, that's OK.
    if [file exists "${prefix}/bin/mtxrun"] {
        system "${prefix}/bin/mtxrun --generate"
    }
}

The main difference is that it runs system "${prefix}/bin/mktexlsr" (with prefix included). The only other difference is that it rebuilds the index also for ConTeXt if installed (which is most likely irrelevant for latexml).

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

Replying to bruce.miller@…:

I think texlive-basic is too low; you'd really want latex or not bother installing tex at all.

OK. But for the buildbot I still see no reason to bother with installing LaTeX first.

I’m not familiar with what LaTeXML does, but if it’s not really useful without LaTeX (which its name sure suggests), then LaTeX should be a dependency.

Remember that we don’t have recommended dependencies or anything, so ports should declare a sane and useful set of dependencies. Providing LaTeXML but requiring the end user to manually install LaTeX does not sound sane at all.

(I would actually try if one could install the file without any tex being present at all. That would speed up the build on the buildbot a lot.)

We should not do what is convenient for the Buildbot infrastructure. We should do what is best for users.

(Half the point of using Buildbot at all is to shift long builds from users’ machines to the buildslaves.)

[mojca (Mojca Miklavec)]

• I'm saying is that we might want different dependencies on the buildbot than on the "user site". It's 100% useless is the buildbot tries to install the complete TeX Live just for the sake of copying one single plain text file under $prefix/share/texmf. Users won't benefit a dime from the buildbot installing the whole TL.

• I'm not familiar with LaTeXML either, but from what I understand it's also useful without TeX to some extent. Currently the default installation doesn't even install any LaTeX style *at all*. So basically users who want to take advantage of some of that functionality have to rebuild it manually anyway. Wouldn't it be so much better and user-friendly if the default installation would ship with those two tiny style files? (It would then be up to users whether they want to install the rest of TeX Live or not. We could still provide a +texlive variant pulling in the dependencies if necessary.)

• Now that I think of it there's no good reason why +texlive and +mactex should conflict (as long as the implementation is adjusted). The variant just installs two additional text files. The port could install those files to both locations, so that users who switch between TeX Live from MacTeX and MacPorts would have latexml fully functional under both systems.

[brucemiller (bruce miller)]

Maybe some background would help to understand a slightly peculiar situation. LaTeXML interacts with a local TeX installation in 2 ways:

• LaTeXML increases the coverage of documents it can convert to XML/HTML by using native LaTeX style files (which it finds using kpsewhich), and can eg. generate images for math (tho' MathML is better! :>) by using latex & various dvi tools. Since currently all the relevant files are found dynamically (via $PATH or kpsewhich), these features will work as long as there is any latex in the search path at run time, whether or not from MacPorts. Almost all users will expect this and consider it a bug when the "obvious thing" doesn't work; they'll want, at least, texlive-latex and any other packages that they expect to use.
• LaTeXML also provides a couple of latexml-specific style files that users can use to customize their LaTeX documents. The documents can be enhanced when converted to XML/HTML with RDFa, CSS, headers, footers, etc; this works out-of-the-box with LaTeXML. But it's important that the documents can also be processed with regular LaTeX, which it can provided the regular versions of the style files have been installed where TeX can find them, usually needing the lsr index to be rebuilt (using mktexlsr).

Consequently, there's no need for a dependency to get the first set of features, although a user needs to be made aware that they probably should install some TeX. The 2nd features is the tricky one and almost could get away without a dependency. (I'll discount clumsy solutions with $TEXINPUTS or editing texmf.cnf)

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?

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? If not, the user would need to.

[mojca (Mojca Miklavec)]

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 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.

[brucemiller (bruce miller)]

After trials & tribulations with Mac upgrades, XCode conflicts, etc, I'm finally(!) making some progress here. It seems the best solution is to have no +texlive variant, but install styles to where texlive would expect them if it were installed. Then a (non-conflicting) MacTeX variant should also install to whereever MacTeX is (I'm dealing with #49507, as well). Since I have a mac-specific situation installing styles to potentially 2 separate directories, it made more sense to deal with that from the Portfile, rather than complicating the generic Makefile.

The MacPorts guide suggests using "file copy" from post-destroot, which works for installing, but unfortunately it seems to go under MacPort's radar: the style files aren't removed when you uninstall the port! I can "delete" the files from post-uninstall, but that seems heavy handed, and I'm unsure how that cooperates with activate/deactivate.

Is this the best solution? Or is there a way to tell MacPorts that there are 2 additional files that it should "manage"?

[brucemiller (bruce miller)]

diff -u Portfile-0.8.1 Portfile

[brucemiller (bruce miller)]

proposed Portfile for LaTeXML

[brucemiller (bruce miller)]

Here's a revision of LaTeXML's Portfile that incorporates several suggested changes. There is no-longer a dependence on texlive, but LaTeXML's style files are installed where texlive would expect them. texlive's mktexlsr is only run if it is present.

The patch also revises the +mactex variant and should fix ticket #49507. The variant is no-longer conflicting (since there is no +texlive variant). A couple of different directories are searched to find where MacTeX is installed, since that has changed with some versions; the style files are then installed wherever MacTeX seems to be.

Could someone please take a look at the diff, and it if seems appropriate, please commit the change. (I don't have write access).

Thanks!

[brucemiller (bruce miller)]

Please see #51818 for the current Portfile (but the diff here may be of interest).

[mojca (Mojca Miklavec)]

Committed in r154083.